[GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis

[Glynn Clements]

Hamish wrote:

> IMO only a module bug or buggy r.mapcalc expression can introduce a nan
> into a grass raster map, and so we shouldn't sweep them under the carpet
> as NULLs. They are distinct- mathematical null vs. spatial null.

I disagree.

I can't think of a single case where a NaN result from a calculation
wouldn't be appropriately represented as null. Either we can make
every single module explicity test for NaN and convert it to a
specific bit pattern, or we can just extend the definition of null
from a specific NaN value to any NaN value.

Note that neither ANSI C nor IEEE-754 specify that a NaN arising from
a calculation will differ from the null value which GRASS uses. 
IEEE-754 defines all values with an all-ones exponent and a non-zero
mantissa as NaN. Exactly which bit pattern you get is an arbitrary
choice made by the CPU designer. On x86, the usual NaN has the first
bit of the mantissa set an all other bits clear. But the all-ones bit
pattern which GRASS uses for null is a perfectly valid NaN value.

Using a specific bit pattern is just creating unnecessary work. E.g. 
it means that we must always pass FCELL/DCELL values via pointers,
just so that we can test for nulls (the compiler and CPU aren't
required to preserve the exact bit pattern of a NaN value, only its
NaN-ness).

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