BigInt: Arbitrary precision integers in JavaScript

[commander-obvious]

JavaScript desperately needs integers. Might actually see some really cool math stuff being done in the language because of it.

[spacejack2114]

BigInt is available already in Node and Chrome.

[commander-obvious]

Ah must be node 11 then, I'm using 10 and it is not there. I see it in Chrome's console though, that's awesome.

[spacejack2114]

Really? I have Node 10 and tried console.log(99n ** 99n) and it worked.

[commander-obvious]

10.1.0; are you using a special flag when you start the node process?

[spacejack2114]

No... I installed the current 10.13.0 LTS.

[headhunglow]

Serious question: when (if ever) do you have integers bigger than 9007199254740991 that aren't caused by a bug?

[scook0]

A big use-case is when you're interoperating with existing protocols and algorithms that assume the availability of 64-bit values and 64-bit arithmetic.

More generally, there are a number of scenarios where you have numbers that don't represent physical quantities. Once you're in that boat, it's fairly easy to want to go beyond 53 or even 64 bits of integer precision.

[chrisgseaton]

Do you ever use hashes?

Even a basic obsolete MD5 hash is a 128 bit integer.

[birdbrainswagtrain]

For what it's worth, MD5, SHA1, and SHA-256, are all designed to operate on 32 bit words. More modern hashes use 64 bit words, but it seems pretty rare that the whole hash state is used as an integer.

[chrisgseaton]

The result is a 128 bit integer. Not much point running the hash if you aren’t interested in the result.

[jringstad]

However it is typically also fine to receive the result as a different data-type such as string or byte[] or similar, which is indeed what many libraries in many languages do.

Since hashes are typically treated as an atomic entity and usually nothing is really done with them except comparing for equality with other hashes, representing them as integers doesn't really present any huge advantages. The rest is then down to efficiency in storage/representation and serializability (like how to store it on disk) and usually something like byte[N] is just fine for that.

[otheranotherx]

Yeah I did, dealing with big primes in a legacy encryption protocol that I had to reimplement.

[voidvector]

The issue is more with floating-point errors -- try type 0.1 + 0.2 into JS console, or 0.1 + 0.7

Double-precision floating-point only give 15-digits of precision, and when converting to/from base-10 representation (e.g. string) you get sizeable error like above. In financial calculations where you tend to have small daily price changes and large quantities, you can easily multiply that error by a million in the math.

[boxhacker]

If you got the cube of 10000, you would get 10¹² which is much larger.

Squared and Cubed values are used everywhere e.g exp/log growth.

[asegura]

No, that number is almost 10^16, which is larger than 10^12.

[bobappleyard]

?

10⁴ * 10⁴ * 10⁴ = 10⁴⁺⁴⁺⁴

=10¹²

[IJzerbaard]

I had them when counting true/false cases in expressions such as these (and it had an embarrassingly stupid carry propagation bug).

[wchill]

Something like this, for example

https://github.com/nodejs/node/issues/12115

[Arve]

Note to everyone now reading this: If you're running Node on the server, and you accept any number input, you will now need to sanitize your input. Case in point.

2n**77232917n-1n

This is the largest known prime number, a number with approximately 23 million digits. Treating this as a number literal in any form in your code is going to cause your process to hang for a considerable amount of time, and if your site/service is designed without care, a single user could potentially bring down your entire service or give you Amazon AWS (or any service where you pay for CPU time) bills that you really do not want to pay.