[GRASS-dev] Re: r.series

[Glynn Clements]

Glynn Clements wrote:

> > it is almost working now. It is only the nan value that is still causing
> > problems - you were right that the computation was correctly done for
> > most of the area but because of the nan value the color table was not
> > set correctly and the resulting map was plain white.
> > I have an area in the series that is set to zero (ocean level) so those
> > are the identical values where I am getting 0/0=nan. I can imagine other
> > situations where this can happen so it would be good to change the nan
> > result to null.
> 
> I've added the following change to CVS, which should catch NaNs:
> 
> --- lib/stats/c_reg.c~	2007-10-23 13:33:32.000000000 +0100
> +++ lib/stats/c_reg.c	2007-10-23 19:34:29.000000000 +0100
> @@ -70,6 +70,10 @@
>  		G_set_d_null_value(result, 1);
>  		break;
>  	}
> +
> +	/* Check for NaN */
> +	if (*result != *result)
> +		G_set_d_null_value(result, 1);
>  }
>  
>  void c_reg_m(DCELL *result, DCELL *values, int n)
> @@ -153,6 +157,10 @@
>  		G_set_d_null_value(result, 1);
>  		break;
>  	}
> +
> +	/* Check for NaN */
> +	if (*result != *result)
> +		G_set_d_null_value(result, 1);
>  }
>  
>  void w_reg_m(DCELL *result, DCELL (*values)[2], int n)

What I forgot to add (and the reason I CC'd to grass-dev), is that
G_is_[fd]_null_value() should probably check for any IEEE NaN, rather
than for a specific bit pattern.

I initially thought about adding such a check to the raster I/O code,
but that doesn't account for cases where nulls are tested for within
the module which generates them.

The main question is whether such a change should be made in 6.3 or
reserved for 7.x.

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