[GRASS-dev] dealing with nan

[Glynn Clements]

Hamish wrote:

> places in the code to look for accidental creation of nan:

> - tan(pi/2)

That should be +/- Inf, not NaN. atan2(0,0) will return NaN, though.

> - GRASS nulls + non-core libgis functions meet mixed endian (?)

GRASS' FP nulls are the all-ones bit patterns, which are unaffected by
endianness issues.

> > The (x != x) test should be portable; OTOH, it's the
> > kind of thing that compilers often get wrong, particularly when
> > optimising (if you ignore NaN, x!=x is always false).
> 
> there is a longstanding wish that 'r.null setnull=' could understand
> nan, so that you could get rid of them.

scanf("%f") etc understand "nan" (case not significant).

However, although "r.null ... setnull=nan" will result in a rule with
low==high==NaN, as NaN is neither less than, equal to, or greater than
itself, testing actual NaN values against that rule will always fail.

> e.g. very rarely r.in.xyz will create them, I am not sure why/how.

Maybe you actually have "nan"s in the file?

> > For 7.0, I intend to change G_is_[fd]_null_value() to treat
> > all NaN values as null, not just the specific bit patterns which
> > it currently uses.
> 
> the only reason I could see to keep them as nan not grass-NULL would
> be for debugging (there is obviously a bug if you get them..).

I'm not proposing changing G_set_[df]_null_value(), only the test. If
the test is changed, there's no reason to explicitly convert "other"
NaN values to the GRASS value (which is just one possible NaN value;
any value with an all-ones exponent and a non-zero mantissa is NaN).

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