-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tally calculation has precision issue #7640
Comments
/cc @sunnya97 |
Sounds reasonable |
Solution: - change `(a / b) * c` to `a * b / c`
I wonder whether this is reproducible with Launchpad too? CC'ing @ethanfrey @njmurarka |
In general However, there is more potential for overflow with the first case. If these are I feel I saw a very similar issue recently. In any case |
So this is actually a bigger problem than it appears to be. I was thinking about your reply @ethanfrey and I was thinking well if order of operations matters so much, we should delay rounding as long as possible which something like So I figured I'd do some tests. As expected Even worse, Looks like we have a bigger problem on our hands. I would say that if we are building "the financial infrastructure of the future", getting arithmetic correct is non-negotiable. I will open up a follow-up issue. Note @odeke-em this sort of stuff is likely good material for fuzzing. |
I think I think there are two approaches, and both may be useful.
The argument to move from |
So would I. I also think we should keep the current API around at least until Happy to do some work on this 👍 |
Did some actual benchmarks here: #7772 Obviously this is just one case to consider of many... but some surprising results:
|
Ideally we'd have proper numerical computing and an interface we want to stick with for
Awesome 👍 |
Created a new issue for addressing all this: #7773 |
@alessio If I recall, weren't we having some issues related to power back in the early part of this year? I think they had to do with the fact that if you had a small # of tokens associated with the stake, your power lost so much accuracy it no longer made alot of sense. The solution was in general to use small units and therefore, all magnitudes were larger. @alessio Is there something I can check to help? I am not clear on what that is. |
Regardless of precision, commutativity is an important fundamental property. I am going to evaluate the issues as well as usages and potential pitfalls. In the future though if performance is a problem but correctness isn't, we can wiggle into high performance, but we shouldn't trade off on correctness at all. |
Summary of Bug
In our test case, validator
V
has voting power1000000000
, someA
delegate10
toV
and vote independently,V
vote yes andA
vote no, current code will calculate tally of no as:which with current decimal settings results in
9.999999999999999000
, which is9
when convert to tokens.I suggest we calculate as:
which should have better result under limited precision.
Version
Steps to Reproduce
For Admin Use
The text was updated successfully, but these errors were encountered: