feat(osmomath): Exp2 function

[p0mvn]

Closes: #XXX

What is the purpose of the change

This PR adds an Exp2 function that computes $$2^{decimal}$$

The following property is used:
$$2^{decimal} = 2^{integer} * 2^{fractional}$$

The integer exponent result is computed using the existing PowerInteger function.

The fractional exponent result is computed using the 13-parameter Chebyshev rational approximation. The numerator coefficients are rounded down and the denominator coefficients are rounded up at the precision end. However, this does not guarantee that the approximated result is always smaller than the actual results (as determined by WolframAlpha).

The Python approximation script is modified to utilize the production coefficients for estimating relative errors. Please see the results:

Additionally, ErrTolerance was refactored to use sdk.Dec for AdditiveTolerance for more accuracy in tests.

In a future PR, Power function with a decimal exponent can be added. This function will use exp2 by utilizing the following property:
x^y = exp2(y * log_2{x})

Testing and Verifying

Tests with links to WolframAlpha were added. The absolute and the relative errors are bounded.

Open Questions

• Is it acceptable that we cannot guarantee rounding behavior?

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes? no
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? yes
• How is the feature or change documented? godocs and approximation scripts

[nicolaslara]

Is it acceptable that we cannot guarantee rounding behavior?

I think as long as the error is within the an acceptable range (from the chart $[10^{-22}, 10^{-27}]$), then I think it doesn't matter if it's higher or lower than the actual results

[p0mvn]

Is it acceptable that we cannot guarantee rounding behavior?

I think as long as the error is within the an acceptable range (from the chart [10−22,10−27]), then I think it doesn't matter if it's higher or lower than the actual results

There are some cases where the error is outside of the chart - 10^17. For example:

osmosis/osmomath/exp2_test.go

Line 112 in 79beaae

AdditiveTolerance: sdk.MustNewDecFromStr("0.00000000000000007"),

I have not been able to explain why that is the case.

One guess is that approximated results in Go are being compared against WolframAlpha. The chart is constructed from a Python library where both the approximations and the actual results are using the same framework. I'm wondering if different computational platforms introduce additional errors.

Please let me know your thoughts.

[p0mvn]

This is how the relative error plot looks like (very similar if not identical to the absolute):

From call, the concern was that relative and absolute plots should not look the same.

On a quick review, I do not see a bug in the way it is calculated. However, I'm going to investigate this better and get back with updates.

[ValarDragon]

What is this smaller than & what is relation to minDecTolerance (sorry not sure if theres some important relation)

[p0mvn]

I used these to implement test cases closer to the boundaries.

The reason is that the errors tend to be large at the boundaries for non-Chebyshev approximations. This is just to make sure that, as expected, Chebyshev does not allow for larger errors close to boundaries. I will add a comment relaying this

[ValarDragon]

Python and actual go code both LGTM, nice job! Still reviewing go tests

[ValarDragon]

The plot difference LGTM

Were actually seeing what we'd expect to see between the absolute error vs relative error

The additive error on RHS side was larger than LHS. The relative error 'dampens' the RHS relative to the LHS, as exp only increasing on the range

[ValarDragon]

Nice job!

[p0mvn]

The plot difference LGTM

Were actually seeing what we'd expect to see between the absolute error vs relative error

The additive error on RHS side was larger than LHS. The relative error 'dampens' the RHS relative to the LHS, as exp only increasing on the range

That makes sense. Thanks for confirming

[p0mvn]

All comments are now addressed. This should be ready for merge once CI passes.