precision over 1000 causing DecimalError for trig functions on a BigNumber

[husayt]

When I try big precisions over 1000 this is the error I get:

: Error. [DecimalError] Precision limit exceededA

If there is a limit to precision, would be nice to document this, otherwise this is an issue

[josdejong]

According to the docs of Decimal.js:

The number of digits of value is not limited, except by JavaScript's maximum array size and, in practice, the processing time required.

Looking in the code of decimal.js though, I see that pi is a hardcoded with 1025 digits (LN10 has the same), and there is an error thrown if you request pi with a higher precision than that:

https://github.com/MikeMcl/decimal.js/blob/master/decimal.js#L33
https://github.com/MikeMcl/decimal.js/blob/master/decimal.js#L3158-L3161

To resolve this I guess we could fallback on calculating pi on the fly with higher precision.

[josdejong]

Note that calculations without pi can be done with higher precision without any issue:

math.config({ precision: 10000 })

math.bignumber(1).div(3).toString() // 0.3333333... many digits...

[husayt]

Why then 1/3 gives me that error when precision is over 1000?

…

On Thu, 17 Jan 2019, 19:38 Jos de Jong ***@***.*** wrote: Note that calculations without pi can be done with higher precision without any issue: math.config({ precision: 10000 }) math.bignumber(1).div(3).toString() // 0.3333333... many digits... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1385 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHXrNxjsb9cRPNyN7gLJFbISdSSrTomks5vENFCgaJpZM4aERuQ> .

[harrysarson]

Could you share an example of code that throws that error?

[husayt]

Yes sure:
https://codesandbox.io/s/9240x1xqzp

Actually, seems problem is not with eval, but with math.format

[josdejong]

That's interesting. Looks indeed that math.format triggers the limit on 1025 that Decimal.js has. Would be great if anyone can look into the cause and possible workaround for this.

On a side note: I think working with a precision over 1000 digits is theoretical? Or is there a real daily use case for this?

[husayt]

We have a number of users of numerics.info working with ultra precise calculations. Some of them use 4000 digits. Especially since library essentially supports this, why to impose unnecessary limitations?

…

On Sun, 20 Jan 2019, 19:21 Jos de Jong ***@***.*** wrote: That's interesting. Looks indeed that math.format triggers the limit on 1025 that Decimal.js has. Would be great if anyone can look into the cause and possible workaround for this. On a side note: I think working with a precision over 1000 digits is theoretical? Or is there a real daily use case for this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1385 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHXrL_rNb4U_l45TrjH7T9RgQjUrOv3ks5vFMHCgaJpZM4aERuQ> .

[ericman314]

I'm taking a look into it right now.

[ericman314]

It fails because the auto config setting causes the formatter to calculate the base 10 logarithm of the bignumber. It compares it to upperExp and lowerExp to see whether it should format in scientific notation or not:

      const exp = value.abs().logarithm()
      if (exp.gte(lowerExp) && exp.lt(upperExp)) {
        // normal number notation
      } else {
        // exponential notation
      }

But value has a property, e, which is equivalent to floor(log10(value)), so replacing the log calculation with the property e works as long as upperExp and lowerExp are integers:

      const exp = value.e
      if (exp >= lowerExp && exp < upperExp) {
        // normal number notation
      } else {
        // exponential notation
      }

I would presume that normally, lowerExp and upperExp would be integers. At least this is the case in all of the unit tests, which continue to pass.

#1387 is a fix that works so long as lowerExp and upperExp are integers.

[husayt]

@ericman314 Thanks for a solution and detailed explanation.

[josdejong]

@husayt is the fix of Eric enough to solve your issue? It means that precision above 1000 digits works for arithmetic operations like multiplication and addition, but still not for trigonometric operations involving pi.

[husayt]

Yes this issue with formatting is thankfully resolved, and yes Pi issue is still on the table and hopefully will find its solution soon. They are related, but separate issues. I noticed in discussion you had a good idea about resolving that too, so looking forward to it . Thanks

…

On Mon, 21 Jan 2019, 20:22 Jos de Jong ***@***.*** wrote: @husayt <https://github.com/husayt> is the fix of Eric enough to solve your issue? It means that precision above 1000 digits works for arithmetic operations like multiplication and addition, but still not for trigonometric operations involving pi. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1385 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHXrJPEG8u0eNQ2dGP9SuAJdOv_CX8iks5vFiFzgaJpZM4aERuQ> .

[josdejong]

👍 then I will keep this issue open as a reminder

[josdejong]

The issue with math.format is now fixed in v5.4.2 thanks to Eric's fix.