Navigation Menu

Skip to content
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

types: Switch from rational usage to decimal #1807

Closed
5 of 8 tasks
ValarDragon opened this issue Jul 24, 2018 · 0 comments · Fixed by #1819
Closed
5 of 8 tasks

types: Switch from rational usage to decimal #1807

ValarDragon opened this issue Jul 24, 2018 · 0 comments · Fixed by #1819

Comments

@ValarDragon
Copy link
Contributor

ValarDragon commented Jul 24, 2018

Summary

Switch Big.Rat usage to a custom-made Big.Decimal implementation.

Problem Definition

Currently we try to round the Big.Rat on most operations (the issue in the last testnet was partly due to us missing the rounding in one spot). However we use bankers rounding for its accuracy. At this point, we may as well be using BigDecimal everywhere. A BigDecimal will be significantly faster than a BigRational. (No GCD on each operation, addition doesn't have any multiplication under the hood, etc.) This will also help with code clarity.

Proposal

Create a BigDecimal type, which has a big int, and an exponent (exponent being an integer). The value represented by a big decimal is (big int value) * (base^exp). The big int in any BigDecimal operation should always have less than some fixed amount of precision. It is an open design decision whether or not to use a single value for precision throughout the SDK, or to have one defined per use case.

Sub-components that must be completed / built before this change should land in a release (per discussion with @jaekwon , @rigelrozanski )

  • Analyze each current use-case of rationals, and determine the precision required. Write this up into a document and include somewhere in the spec. Additionally write down the expected range of values for the relevant values.
  • Write regression tests for the rounding behavior.
  • Ensure that inflationary rewards are non-zero for values in the expected range.
  • Determine if the base should be 2 or 10. The argument for a base of 10 is that for things like comission, a small discrepancy between the value reported by the validator, and the actual value could cause problems. The argument for base 2 is increased efficiency gain, and perhaps the previous point having insignificant consequences with suitably high precision.

The places where rationals are currently used are roughly slashing, provisions and inflation.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants