[GRASS-dev] [gdal-dev] Setting NODATA to -nan

[Glynn Clements]

Even Rouault wrote:

> - I've had a look at https://trac.osgeo.org/grass/changeset/65602 and my 
> understanding is that now a pixel value at NaN will be considered as null, 
> even if null_val is not NaN (but this is perhaps intended, if so, ignore 
> this). 
> 
> - This is just for the sake of my curiosity: do you know how -nan pixel values 
> can be generated by GRASS in practice ? (This was what triggered all this: the 
> GDAL reporter was surprised to see pixels at -nan and nodata at nan, and 
> thought that something was wrong)

Rast_set_d_null_value() and Rast_set_f_null_value() use the all-ones
bit pattern. This is one of the many NaN values (anything with an
all-ones exponent and a non-zero mantissa is NaN). As the topmost bit
(i.e. the sign bit) is set, it's possible that some code would
consider that to be "-NaN". E.g. code which writes a leading "-" based
upon the sign bit before considering the other components would do so.

Rast_is_d_null_value() and Rast_is_f_null_value() treat any NaN as
null (specifically, they test whether the value is unequal to itself).

At one time, these functions (or rather, their predecessors) checked
explicitly for the all-ones pattern, but this was changed (in r33717
and r33752) to improve robustness. Apart from code explicitly setting
a value to "null", NaNs can arise from calculations (0.0/0.0, sqrt(x)
or log(x) for x<0, asin(x) or acos(x) for abs(x)>1, etc), and there's
no guarantee as to exactly which NaN representation will result.

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