performance of pow function

[rbro]

performance of pow function

[MikeMcl]

Among other reasons, bcmath is a compiled C extension so it will of course be much faster.

In this library, the pow function can be slow as it always calculates its result (or, if the exponent is negative, its intermediate result) to full precision without rounding.

In your example, the function will first calculate 1.0011012345678²⁰⁰⁰, the result of which is over 26000 digits long. Then, because the exponent is negative, the function will calculate and return the inverse, which will be rounded because it's a division operation.

So, although you will only see a result with as many decimal places as you have specified with config, behind the scenes the function will have perfomed many intermediate operations on numbers thousands of digits long - and that takes time.

It is a 'feature' of this library that all arithmetic operations are lossless, i.e. unrounded, except those involving division. This makes it hard to lose precision and makes the library simple to use, but as you have discovered it makes the pow function unviable for anything other than small integers.

What is the solution? The short answer is that the pow function needs to calculate its result to a limited number of significant digits. I did implement this in what was to be version 2 of this library, but I ended up making many other changes and eventually decided to release it separately as decimal.js. That is a more suitable library if you want to do power operations with larger exponents.

[rbro]

Michael - thanks for your quick and detailed explanation. One question about decimal.js:

I see in decimal.js that the round function doesn't take any parameters, so it always rounds to a whole number. Is toDecimalPlaces in decimal.js the equivalent of round in bignumber.js? In other words, how can I do a calculation with a certain precision for the intermediate calculations, but then round the result to a lower precision?

For example, in bignumber.js, I can do:

var a = new BigNumber(1.125).plus(0.001).round(2);

and it returns 1.13.

Would the equivalent in decimal.js be:

var a = new Decimal(1.125).plus(0.001).toDecimalPlaces(2);

Thanks again for your help

[MikeMcl]

Yes, that is correct.

In decimal.js the round method just follows Math.round behaviour and rounds to an integer because of the ambiguity of whether the rounding is to decimal places or significant digits.

Your example would work fine unless you have previously set a Decimal.precision of less than 3, as in decimal.js all arithmetic operations are only performed to the number of significant digits specified by the current precision setting.

Please ask any further questions about decimal.js in its own issues section.

[MikeMcl]

TODO: Implement a global maximum precision setting in terms of significant digits for bignumber.js, in addition to the current division decimal places setting. This may also solve the issue of adding numbers with massively different exponents which is also currently so slow as to be unviable.

[MikeMcl]

Added a POW_PRECISION configuration option in v2.0.1, so the number of significant digits calculated by the power operation can be limited. This has greatly improved its performance.