Floating-point precision

A counter adds 0.1 every tick. After ten ticks the chip asks beq tenths 1 done – and never jumps. The code is right, the number is not quite. Today is about what a register really stores.

53-bit mantissa#

Every register is a double precision decimal: 53 bits for the digits, plus an exponent that moves the point. Two rules follow from that:

1. Whole numbers up to 2^53 are exact. Above that, bits for the last digits are missing.
2. Most decimal fractions are not exact. 0.1 is an endless fraction in binary, like 1/3 in decimal. The nearest number is stored.

Rounding errors#

add r0 0.1 0.2 gives 0.30000000000000004. That is not a bug of the game, every computer working with decimals does this. seq r1 r0 0.3 therefore returns 0.

add sum 0.1 0.2              # 0.30000000000000004
seq exact sum 0.3            # 0, not equal
sap approx sum 0.3 TOLERANCE   # 1, close enough

You have known the solution since day 109: compare with a tolerance. sap checks whether two values are relatively close to each other. For controls a hysteresis with sgt and slt is better than an equality test anyway.

Numbers like 0.5, 0.25 or 0.125, on the other hand, are exact – they are binary fractions. A counter in half seconds therefore stays exact.

Large numbers#

Above 2^53 = 9,007,199,254,740,992 units get lost:

add loss BIG 1           # 2^53 + 1 becomes 2^53
sub loss loss BIG     # 0 instead of 1

In the game you hit the limit mostly when packing: values with more than 53 bits together lose their lowest bits.

Large hashes in a register#

Hashes look big, for example −1252983604 for the gas sensor. But they are 32-bit numbers and therefore fit into a register easily and exactly. seq on two hashes is therefore safe, even though care is needed with decimals otherwise.