[GRASS-dev] dealing with nan

Hamish hamish_b at yahoo.com
Mon May 19 04:09:04 EDT 2008


> Yann Chemin wrote:
> > I have some data that reads as "nan", while
> > rare, it may happen when compressing/uncompressing
> > GRASS Locations to ship them across Internet.

what method are you using to compress/decompress?
..zip? .tar.gz? r.pack/r.unpack?

if r.pack I think it is safer to use the script in the trac wish patches which converts GRASS <=6 raster dir layout to proposed GRASS 7 $MAPSET/raster/$NAME/element) then tarball up the map's dir, and vice versa. I should probably update r.pack not to use r.{in|out}.mat as that will lose some metadata for sure.


places in the code to look for accidental creation of nan:
- (x/y) where both the x and y variables could sometimes be 0.
- tan(pi/2)
- r.in.mat/r.out.mat use Matlab's NaN to store grass NULLs
- GRASS nulls + non-core libgis functions meet mixed endian (?)
- ?


> > I would like to know how to deal with them in GRASS
> > raster programming, so that they are:
> > 1 - detected
> > 2 - set to null

Glynn:
> 	if (x != x)
> 		G_set_d_null_value(&x, 1);
> 
> There is also isnan(), which is in C99, and also specified
> by POSIX:
> 
> 	http://www.opengroup.org/onlinepubs/009695399/functions/isnan.html
> 
> However, I don't know if it exists on all platforms
> which we care about. MSDN says that MSVCRT has _isnan() (with a
> leading underscore), but it's defined in <float.h> rather than
> <math.h>.
> 
> 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. e.g. very rarely r.in.xyz will create them, I am not sure why/how.

 
> 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..).


Hamish



      



More information about the grass-dev mailing list