Approximately zero: sapz, snaz, bapz, bnaz

Yesterday you saw that a relative tolerance becomes tiny near zero. The z variants of the ap instructions compare against zero. Whoever expects them to check “approximately zero” with some leeway is in for a surprise.

What sapz really checks#

In the game code sapz r? a c is nothing but sap r? a 0 c. So the condition reads: the magnitude of a is at most max(c × magnitude of a, float.epsilon × 8).

The first part, c times the magnitude of a, is smaller than the magnitude itself for any tolerance below 1. It never helps. What remains is the fixed floor float.epsilon × 8, about 1.1 · 10⁻⁴⁴. That is the smallest tolerance the ap instructions have, and at zero it is the only one that takes effect.

So sapz checks for exactly zero, like seqz. A remainder from 0.1 + 0.2 − 0.3 does not count as zero:

add r0 0.1 0.2
sub r0 r0 0.3      # r0 is a tiny remainder, not 0
sapz r1 r0 0.5     # r1 = 0

Epsilon is not the tolerance#

There is also the constant epsilon. It is about 5 · 10⁻³²⁴, the smallest number above zero the chip can represent. It has nothing to do with the float.epsilon × 8 limit of the ap instructions. Whoever writes sap r0 a b epsilon compares practically exactly.

Approximately zero with a limit of your own#

For “almost zero” you need an absolute limit in the unit of the value:

sub diff inside outside
abs diff diff
slt equal diff 0.5         # less than 0.5 kPa difference

That also works in a vacuum, where the relative tolerance of sap fails. The z instructions remain for values that are exactly 0 by nature: counters, counts, 0/1 flags.