3 ms·

If you deal with money, you do have to store the fraction separately anyway and clearly should not use floating point. But that's beyond the point. The upper bo

If you deal with money, you do have to store the fraction separately anyway and clearly should not use floating point. But that's beyond the point. The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, not to tempt you to simply represent the amount in a double.

akersten 6y ago
> The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, I think that is a far too generous read of the document. I think it's because they wanted you to be able to use a JS Number to store the value, which is the Wrong Thing To Do. In fact, using two BigInts to separately represent the fractional and whole pieces of the currency would be far better. This is the kind of ambiguity that I refer to when I say this is underspecified.
- chrismorgan 6y ago
  Eh, it’s not underspecified. It’s just… strangely specified, in a way that people will ignore and misparse. But then, if it had been specified in any other way people would have ignored and misparsed it too.
  - lanstin 6y ago
    People going to put money in floats unless you make it impossible. Then they send it via json and round and probably over or under flow and all sorts of amusing bugs result.
- michaelt 6y ago
  If JavaScript numbers work up to 2^52 that could precisely represent $45 trillion in cents. IMHO if they had a choice between dropping Javascript support in preference of languages with BigInt support, or dropping support for payments larger than $45 trillion, they probably made the right decision.
  - megous 6y ago
    Javascript has bigint support. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...