Arbitrary-precision integers

[hikari-no-yume]

Currently they're limited to 32-bit since that's all JS supports. They're supposed to be bigints.

[hikari-no-yume]

See: https://github.com/TazeTSchnitzel/Firth/blob/217a4a044792b79101e867d23e7b66bef3c06e4f/src/utils.js#L5

[mathroc]

I would suggest using http://mikemcl.github.io/bignumber.js/ here

[hikari-no-yume]

Seems like overkill. That's an arbitrary-base, arbitrary-precision floating-point library. What we need is a fast arbitrary-precision integer library. What you've suggested is certainly workable, but it's not ideal.

[mathroc]

well I was suggesting because it also supports floating point numbers. that would mean easier implementation of interaction between integer and float, they would of the same type. but I agree that it might not be as fast as https://www.npmjs.com/package/bignum ( but I think this one does not work in the browser) or https://www.npmjs.com/package/big-integer

[raoulvdberge]

+1 for having one number type. In my custom implementation of Firth I just use Java's BigDecimal, that support very big numbers AND floating point numbers.

[hikari-no-yume]

To be useful you need at least three number types, unfortunately:

• 64-bit (or bigger) integers, if you're going to interact with anything with large integer IDs
• 64-bit IEEE 754 floats, since they're the kind of floats virtually everything uses and are natively supported
• Decimals of some kind, because we're human, and money etc. requires this

You could have just one type, but each has its own problems:

• Just integers? Well, now you need to do fixed-point everywhere, and you'll still need a float type in lots of places if you do, for example, graphics
• Just floats? Well, a 64-bit float can't fit a 64-bit integer, so you end up with interoperability issues like JavaScript has
• Just decimals? Well, can your decimals fit a 64-bit integer? If not, same problem as with floats. And you'll need to do lots of conversions, losing precision, to deal with things which expect floats

I'm also not sold on arbitrary-precision floats or decimals, because unlike arbitrary-precision integers we can't just choose precision for you on-the-fly, given how common numbers with recurring digits are.

[mathroc]

ok, I take back what I said. I also did some performance tests between javascript numbers and BigNumbers. the BigNumber lib is also much slower ( ~600 times slower in most of my tests ) so I guess it's not really an option. while doing that i realised that javascript literal numbers are of the same type (typeof 1.1) === (typeof 1) at least when the user is concerned.

Do you have any reading on the matter you could point me too ?

[hikari-no-yume]

JS has a single number type, Number, which is an IEEE 754 double-precision float. This works okay most of the time, but unfortunately integers larger than 54 bits lose precision when converted to double-precision floats, and that's a problem given how common 64-bit IDs are for things. That caused problems for Twitter when the number of tweets crossed the 54 bit mark. Also, it's not very human-friendly, because 0.1 + 0.2 !== 0.3, for example.

I'm not sure what to point you to, though.