JavaScript Numbers Like You’ve Never Seen Them Before

Slides

One person suggested this talk should be “don’t use JS for maths…”

The most reported bug in js: 0.1 + 0.2 != 0.3 (eg. 0.30000000000004) …so what is actually going on here?

A brief history of maths… we have had different number systems through history; and new understandings and rules on how to use them.

Humans like to count in 10s. Nobody really knows why but it’s probably to do with having ten fingers. Computers prefer 2s (powers of two underpin binary).

IEEE-754: a not-free standard that defines formats for numbers, interactions, and so on. It’s used in lots of modern programming languages and devices. It is a little bit like scientific notation. 5.6 x 10(power of -9)

• The sign: positive or negative (1bit)
• Exponent: exponent – bias (very hard to write this bit down!)
• Mantissa: (always assumes it is preceded by 1. – one-dot)
• Special values: NaN, Infinity, 0, -Infinity, -0.

There is an IEEE-754 calculator online which helps understand this system. So why do we care?

All numbers in JS are 64 bit IEEE-754 floating point values.

Value Representation

Original	Stored as
0.5	0.5
0.25	0.25
0.1	0.100000000014351 (not the real number used in presentation)

Some numbers don’t store quite right. Think of it like trying to produce 43c in Australian currency – you simply cannot do it, because we don’t have the coins to add up to that value (no 1c or 2c).

So we get some calculation problems.

Integers are always stored exactly, but people tend not to work purely in Ints because it’s a little clunky. Much better to use a library:

• bigdecimal.js (beware: not easy to read or understand)
• math.js
• decimal.js
• big.js

Issues with this? Speed. The libraries are not as fast as native. Also you can’t generally do things you’d expect like x+y, you have to things like sum(x,y) or similar syntax.

Comparing numbers can be made more predictable by including a margin of error (noting small differences usually noted with the epsilon symbol, so expect to see that in examples.)

But what about the future? These things aren’t great… so what might happen:

• Decimal type: long standing debate in the ECMAscript community. Has been discussed since v3. But lots of concern about interoperability.
• Value types proposal
• ES2016? Unlikely.

Other issues not even discussed…

• rounding
• exceeding limits (eg. Number.MAX_SAFE_INT+2)
• problems parsing json
• parseInt, parseFloat radix param

Conclusion

• all numbers stored in IEEE-754, no matter what anything ever tells you
• some values can’t be represented in IEEE-754
• libraries can help
• one day the value type proposal could enable quite a lot of new things