fix: increase sdk.Dec maxApproxRootIterations

[catShaark]

Description

ApproxRoot return incorrect value for large sdk.Dec because maxApproxRootIterations is not big enough, I increase it to 300

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[julienrbrt]

Can we add a benchmark on ApproxRoot and an extra test case?

[ValarDragon]

LGTM, lets just add a test case that used to fail?

We merged this into Osmosis

Also the current AppproxRoot behavior is imo unsafe, it needs to be returning an error or a flag at minimum, if it can't converege within max iterations, so the caller doesn't have incorrect expectations.

This actually would have seriously affected Osmosis in edge-cases that (thankfully) were not hit on mainnet.

[alexanderbez]

@catShaark could you possibly address @ValarDragon's concerns (test case + returning an error) prior to us merging this PR?

[aaronc]

Can we just start migrating to APD soon?

[catShaark]

@catShaark could you possibly address @ValarDragon's concerns (test case + returning an error) prior to us merging this PR?

Yes, and from playing around with the function, I have some concerns of mine as well :

• Right now the function will panic "out of bound" for very large sdk.Dec even if it has smaller bit len than maxDecBitLen. I think this is because we're using Newton-Raphson method with the initial guess of 1, which in cases of large input, makes the second guess far far exceeds the actual root value, causing the "out of bound" . We can fix this by including some condition check for guesses in the function but idk if this is the best way.

• There's inaccuracy due to not enough precision, for example :

  ApproxSqrt(2290630776557940645655329181699877738996280875636842527) =
  1513482995133391198305976331.737501099575432618 but
  1513482995133391198305976331.737501099575432618 ^ 2 =
  2290630776557940645655329181699877738996280876203567639

  If we support dec as big as 256bit, we might as well increase precision to ensure accuracy for operation like
  AppoxSqrt, or we switch to APD like @aaronc said

• I propose we make separate functions for calculating square root and cube root like this one implementation here.

[catShaark]

Also the current AppproxRoot behavior is imo unsafe, it needs to be returning an error or a flag at minimum, if it can't converege within max iterations, so the caller doesn't have incorrect expectations.

Yes, I'll handle this.

[ValarDragon]

Agreed that sqrt and cubed root should generally be different, dedicated functions.

Also agreed that we should switch to apd, but I'm not sure that we get to avoid maintenance for decimal for quite some time.

Perhaps we compile the issues you point out as well @catShaark into a second issue, and the flag for could-not-converge?

IMO it suffices for this PR if we just get a test case that would return something way off before, and is now fixed by bumping the iteration count

[aaronc]

See #11783. Regen has prior work with apd that we can leverage

[aaronc]

Also not sure we can avoid maintaining the current dec or not. It would be state machine breaking but maybe that's okay in the next release? At least we need something that supports Dec's (incorrect) binary encoding

[alexanderbez]

@catShaark approved! Please add a changelog entry and I'll merge this. Should we backport this to 0.45?

[julienrbrt]

I am not sure that this is the right way to test this. Now we just test ApproxRoot with different maxApproxRootIterations values, without actually testing the actual implementation (although it tests with 300 it is not clear from the test only that it is the default value).

I think we should just add one test case in TestApproxRoot that fails with 100 but passes with 300.
I don't think we need that extra TestApproxRootLargeDec nor having MaxApproxRootIterations public.
Moreover, we should update the comments in the tests that still mention 100 iterations.

[ValarDragon]

Agreed that the variable shouldn't be exposed / altered, a simple one-off test vector suffices

[catShaark]

I think we should just add one test case in TestApproxRoot that fails with 100 but passes with 300. I don't think we need that extra TestApproxRootLargeDec nor having MaxApproxRootIterations public. Moreover, we should update the comments in the tests that still mention 100 iterations.

Got it

[julienrbrt]

lgtm