I think Davide could shed some light on this situation.

Here's how the zero-level values work: when `$a`

is compared to `$b`

, if either value is below the `$zeroLevel`

value, which is `1E-14`

by default, then if the *difference* between the two is less than `$zeroLevelTol`

, which is `1E-12`

by default, then they are equal. That is, if `abs($a) < $zeroLevel || abs($b) < $zeroLevel`

, then the two are considered equal if `abs($a - $b) < $zeroLevelTol`

, and are not equal otherwise.

In the case discussed here, the correct value is given by `pi/6*500*cos(pi/2)`

, which evaluates to `1.60305891143483e-14`

, and the test value is `500*cos(pi/2)`

, which is `3.06161699786838e-14`

, neither of these is less than `$zeroLevel`

, so the usual relative tolerance rules are used, and they are **not** equal by that measure (since they would have to agree on their first 3 or 4 significant digits).

On the other hand, when testing against `100*cos(pi/2)`

, which is `6.12323399573677e-15`

, this value *is* less than `$zeroLevel`

, and so the rules above come into play, and we must compare the *difference*, which is `-9.90735511861148e-15`

, to the `$zeroLevelTol`

of `1E-14`

in absolute value, and since it is less than the tolerance, these **are** considered equal.

When testing against the answer of `0`

itself, since that is less than `$zeroLevel`

, the zero-level rules are used, and since the difference between `pi/6*500*cos(pi/2)`

and `0`

is `1.60305891143483e-14`

, and that is less than the `$zeroLevelTol`

of `1E-12`

, these are also equal.

Finally, for `260*cos(pi/2)`

, which is `1.59204083889156e-14`

, neither is smaller than `$zeroLevel`

, and so the usual relative tolerance is used, and this don't match `1.60305891143483e-14`

to enough digits, so they aren't equal. On the other hand, `262*cos(pi/2)`

does match to enough digits, so that **does** match `pi/6*500*cos(pi/2)`

.

So that is how it works, and why these examples do what they do.