You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 )
The places where rationals are currently used are roughly
slashing
,provisions
andinflation
.For Admin Use
The text was updated successfully, but these errors were encountered: