proposal-decimal VS 0.30000000000000004

Bloomberg are currently sponsoring Igalia to work on adding native Decimal number support to JavaScript.

https://github.com/tc39/proposal-decimal

This is an active proposal and was last discussed in the September 2023 meeting.

would it be possible, for example, to access the standard decimal library of C# or Python via Javascript, thus not having to wait for the TC39 spec / implementation? [1]

[1] https://github.com/tc39/proposal-decimal

There's a BigDecimal TC39 proposal to bring this kind of thing to the native language, but until then you have to choose between accuracy and performance.

To solve the problem while JavaScript waits on its own BigDecimal API, you can use something like bignumber.js to perform your calculations.

TC39 is now advancing Built-in decimal datatype in JavaScript.

given the popularity of javascript, it's about time we had better native tools for dealing with numbers in general, but it seems like the discussion is very slow on this front. for instance, the decimal proposal is still at stage 1 [1]. and no, BigInt does not solve that.

[1] https://github.com/tc39/proposal-decimal

In the future, JavaScript will hopefully get base 10 arithmetic: https://github.com/tc39/proposal-decimal

https://0.30000000000000004.com/

Although it would be good to move in the direction of using a BigDecimal equivalent by default when ingesting unknown data.

There's no such thing as precision for floats. Floating-point calculations are always inaccurate: read this: https://0.30000000000000004.com/

Edit: This specific example even has its own website: https://0.30000000000000004.com/

In everyday math, we know adding 0.6 + 0.3 equals 0.9, right? But when we turn to computers it results in 0.8999999999999999. Surprisingly, this doesn’t just happen only in JavaScript; it’s the same in many programming languages like Python, Java, C too. Also, it’s not just about this specific calculation. There are many more decimal calculations showing similar not-quite-right answers.

Surprisingly common values like 0.1 don't have a precise representation in binary for most formats, including standard floating point number formats. See https://0.30000000000000004.com/ for more detail than you can shake a stick at.

Also if the local tax code states using 5 decimal places for intermediate values when you will introduce “errors” using formats that give greater precision as well as those that give less precision. Having work on mortgage and pension calculations I can state that the (very) small errors seen at individual steps because of this can balloon significantly through repeated calculations.

Furthmore, the name floating point gives away the other issue. Floating point numbers are accurate to a given number of significant figures not decimal places. For large numbers any decimal places you have in the result are at best an estimate, and as above any rounding errors at each stage can compound into a much larger error by the end of a calculation.

You'll love this https://0.30000000000000004.com/