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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
