# What is the standard solution in JavaScript for handling big numbers (BigNum)? [closed]

Is there a bignum library for JavaScript or built-in that I can include like

``````<script type="text/javascript" src="the_bignum_library.js"></script>
``````

?

I think my users would prefer to enter numbers in a web page and wait 7 seconds for a result, rather than download an executable and click through a bunch of "this executable could possibly harm your computer" warning screens to install it.

I've considered basing my own off of http://github.com/silentmatt/javascript-biginteger or http://www.mainebrook.com/john/fun/euler.html. Or would you recommend calling from JavaScript into a Java bignum library such as apfloat?

25

Update(2019-08-19): BigInt is now part of Firefox and Chrome; you no longer need a library:

``````const bigInt1 = 1111111111111111111111111111111n;
const bigInt2 = BigInt("1111111111111111111111111111111")
console.log((bigInt1 + bigInt2)+"")``````

If you need arbitrary-precision decimal numbers, use Javascript-bignum, as it is correct and fast.

Tuesday, June 1, 2021

76

There are basically two major pitfalls people stumble in with floating-point numbers.

1. The problem of scale. Each FP number has an exponent which determines the overall “scale” of the number so you can represent either really small values or really larges ones, though the number of digits you can devote for that is limited. Adding two numbers of different scale will sometimes result in the smaller one being “eaten” since there is no way to fit it into the larger scale.

``````PS> \$a = 1; \$b = 0.0000000000000000000000001
PS> Write-Host a=\$a b=\$b
a=1 b=1E-25
PS> \$a + \$b
1
``````

As an analogy for this case you could picture a large swimming pool and a teaspoon of water. Both are of very different sizes, but individually you can easily grasp how much they roughly are. Pouring the teaspoon into the swimming pool, however, will leave you still with roughly a swimming pool full of water.

(If the people learning this have trouble with exponential notation, one can also use the values `1` and `100000000000000000000` or so.)

2. Then there is the problem of binary vs. decimal representation. A number like `0.1` can't be represented exactly with a limited amount of binary digits. Some languages mask this, though:

``````PS> "{0:N50}" -f 0.1
0.10000000000000000000000000000000000000000000000000
``````

But you can “amplify” the representation error by repeatedly adding the numbers together:

``````PS> \$sum = 0; for (\$i = 0; \$i -lt 100; \$i++) { \$sum += 0.1 }; \$sum
9,99999999999998
``````

I can't think of a nice analogy to properly explain this, though. It's basically the same problem why you can represent 1/3 only approximately in decimal because to get the exact value you need to repeat the 3 indefinitely at the end of the decimal fraction.

Similarly, binary fractions are good for representing halves, quarters, eighths, etc. but things like a tenth will yield an infinitely repeating stream of binary digits.

3. Then there is another problem, though most people don't stumble into that, unless they're doing huge amounts of numerical stuff. But then, those already know about the problem. Since many floating-point numbers are merely approximations of the exact value this means that for a given approximation f of a real number r there can be infinitely many more real numbers r1, r2, ... which map to exactly the same approximation. Those numbers lie in a certain interval. Let's say that rmin is the minimum possible value of r that results in f and rmax the maximum possible value of r for which this holds, then you got an interval [rmin, rmax] where any number in that interval can be your actual number r.

Now, if you perform calculations on that number—adding, subtracting, multiplying, etc.—you lose precision. Every number is just an approximation, therefore you're actually performing calculations with intervals. The result is an interval too and the approximation error only ever gets larger, thereby widening the interval. You may get back a single number from that calculation. But that's merely one number from the interval of possible results, taking into account precision of your original operands and the precision loss due to the calculation.

That sort of thing is called Interval arithmetic and at least for me it was part of our math course at the university.

Tuesday, June 1, 2021

36

This blogpost contains an example, fairly foolproof implementation, and detailed theory behind it http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ it is also one of a series, so you can always read more. In short: use ULP for most numbers, use epsilon for numbers near zero, but there are still caveats. If you want to be sure about your floating point math i recommend reading whole series.

Wednesday, June 2, 2021

85

The lmapm library by Luiz Figueiredo, one of the authors of the Lua language.

Monday, June 14, 2021

20

@High Performance Mark's suggestions are very good, and I highly recommend the ISO_C_Binding of Fortran 2003 (supported by numerous Fortran compilers) for interoperability between Fortran and C -- there is a larger issue here that makes the ISO_C_Binding more useful: Fortran allocatable arrays are more complicated then ordinary arrays. If you "hack it" and directly pass a pointer to the C code, you are likely to pass a pointer to a Fortran internal structure describing the allocatable array rather than a pointer to the sequence of numeric values. Allocatable arrays aren't directly supported by the ISO_C_Binding, but should work if you write an ISO_C_Binding interface (unlike what I wrote originally) -- the book "Fortran 95/2003 explained" says that the compiler will recognize the the called routine isn't receiving an allocatable array and will perform copy-in/copy-out to match the arrays.

P.S. My guess is that copy-in/copy-out shouldn't be necessary for a simple allocatable actual argument. When the compiler recognizes via an explicit interface (which could be an ISO_C_Binding interface) that the dummy argument of the called routine is not an allocatable, the compiler should just be able to extract the pointer to the actual array from the description of the allocatable and pass that as the argument. Copy-in/copy out will be required in some cases, such as a pointer to a non-contiguous array, such as pointer with a non-unit stride (e.g., a pointer that points to elements 1, 3, 5, ...). But without any interface, the compiler will likely pass the descriptor of the allocatable array, which won't be what C is expecting....

Thursday, August 26, 2021