[GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it

[Glynn Clements]

G. Allegri wrote:

> If logical operator is applied to, sat, Byte data it gives true/false
> results, e.g. if(A && B,1, 0) behaves correctly even with cell values
> values greater then 1.
> That's why I expected it to work with floats operands too.
> >From a user perspective if it works for a cell with value 2 it should also
> work for a cell with value 2.0.
> That'all.

r.mapcalc's interpretation of booleans is borrowed from C. Booleans
are just integers where zero is false and non-zero is true.

But that doesn't necessarily make much sense for floats; the
conventional wisdom is that comparing a float for equality with zero
is usually a mistake, as results which should mathematically be equal
to zero often aren't actually equal to zero due to intermediate
rounding errors. In some cases, simply subtracting a number from
itself won't yield zero (e.g. due to the x87 FPU using 80 bits for
floating-point registers while values stored in memory use 32 or 64
bits).

You can obtain C-like behaviour by converting to an integer with the
int() function then using that; the result is that any value between
-1.0 and 1.0 (excluding both endpoints) will be considered false while
anything else is true. Or you can convert to an integer with the
round() function and use that, in which case any value between -0.5
and 0.5 (including both endpoints) will be false while anything else
is true. Or you can compare for equality with 0.0, in which case -0.0
and 0.0 will be false while anything else is true. Or you can compare
the magnitude (obtained using abs()) to an "epsilon" value so that
anything smaller than the expsilon is false while anything larger is
true.

That's four different possibilities, none of which is any more
"correct" than any of the others. Choosing one of them would just mean
that r.mapcalc was probably using the "wrong" one, and doing so
silently. The current behaviour forces the user to be explicit.

-- 
Glynn Clements <glynn at gclements.plus.com>