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
As part of v1.4.0, the PowPrecisionNegativeExponent was added, which limits the default precision of Pow() when using negative exponents to 16. When using this package to express amounts of crypto assets, 18 decimal places is extremely common. Storing balances/transfer amounts in the smallest possible decimal (e.g. in case of ETH, storing the amounts in wei) is standard practice. Converting these amounts to and from a more human-readable format (or the corresponding amount in ETH), I rely on a fair amount of code that looks somewhat like this:
This worked fine before updating the dependency version, where there was no cap on the negative exponent when calling Pow. For my use-case, setting this value to at least a sensible default makes more sense, but truthfully, I believe a negative exponent ought not to be capped. Using 10^-N is an expression of precision in and of itself.
As part of the linked PR, I've also increased the default division precision to 18 for the same reason as above (crypto assets having 18 decimal places). I've kept it as a separate commit, which I can revert if needed.
As part of v1.4.0, the
PowPrecisionNegativeExponent
was added, which limits the default precision ofPow()
when using negative exponents to 16. When using this package to express amounts of crypto assets, 18 decimal places is extremely common. Storing balances/transfer amounts in the smallest possible decimal (e.g. in case of ETH, storing the amounts in wei) is standard practice. Converting these amounts to and from a more human-readable format (or the corresponding amount in ETH), I rely on a fair amount of code that looks somewhat like this:This worked fine before updating the dependency version, where there was no cap on the negative exponent when calling
Pow
. For my use-case, setting this value to at least a sensible default makes more sense, but truthfully, I believe a negative exponent ought not to be capped. Using10^-N
is an expression of precision in and of itself.As part of the linked PR, I've also increased the default division precision to 18 for the same reason as above (crypto assets having 18 decimal places). I've kept it as a separate commit, which I can revert if needed.
PR: #379
The text was updated successfully, but these errors were encountered: