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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
