3 ms·

I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.

• dfabulich 5y ago
  JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.
  • runarberg 5y ago
    How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple (a, b, c) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`. Is there a better way?
    • lbussell 5y ago
      What about a 2-tuple with two numbers, one being the BigInt and one being the exponent. So 1.000054 would be (1000054, -6) = 1000054*10^(-6). Yours is probably more space efficient though.
      • wizzwizz4 5y ago
        Yours is more space-efficient for real-world numbers.
      • nine_k 5y ago
        This is basically floating-point. IEEE 754, BTW, allows for 10-based floats, but IDK if anybody uses it.
• dragonwriter 5y ago
  The decimal proposal is a vague enough that it is unclear if it would improve on that; if it was arbitrary-precision decimals, that would be an improvement. If it is limited precision but better than Number (seems unlikely), it would be an improvement. If it is limited precision but not better range/precision than Number, just decimal rather than binary floating point, its probably not an improvement. The proposal is vague enough that any of those would fit.