Glynn,
On Tue, Oct 7, 2008 at 12:02 PM, <svn_grass@osgeo.org> wrote:
Author: glynn
Date: 2008-10-07 06:01:59 -0400 (Tue, 07 Oct 2008)
New Revision: 33717Modified:
grass/trunk/lib/gis/null_val.c
Log:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
/me backport this?
Markus
Markus Neteler wrote:
> Author: glynn
> Date: 2008-10-07 06:01:59 -0400 (Tue, 07 Oct 2008)
> New Revision: 33717
>
> Modified:
> grass/trunk/lib/gis/null_val.c
> Log:
> Make G_is_[fd]_null_value() check for any NaN, not just all-ones/me backport this?
Maybe.
Unless there are modules which genuinely need to distinguish GRASS
nulls from other NaNs, the only real risk is a broken compiler
"optimising" the "x != x" test away.
At one time, that was quite likely, but compilers tend to be better
nowadays (i.e. gcc has effectively destroyed the market for half-baked
C compilers).
Although it's a very small risk, if it does break, it's rather
significant.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
fwiw, I consider this a rare, but potentially very important change to
the raster engine.
Markus:
> /me backport this?
Maybe.
Unless there are modules which genuinely need to distinguish GRASS
nulls from other NaNs,
It can help in tracking down bugs, e.g. see the BUGS section of the
r.in.xyz man page.
IMO only a module bug or buggy r.mapcalc expression can introduce a nan
into a grass raster map, and so we shouldn't sweep them under the carpet
as NULLs. They are distinct- mathematical null vs. spatial null.
Hamish
Wouldn't it be interesting then to have G_is_[fd]_nan_value()?
2008/10/8 Hamish <hamish_b@yahoo.com>:
Glynn:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
fwiw, I consider this a rare, but potentially very important change to
the raster engine.Markus:
> /me backport this?
Maybe.
Unless there are modules which genuinely need to distinguish GRASS
nulls from other NaNs,It can help in tracking down bugs, e.g. see the BUGS section of the
r.in.xyz man page.IMO only a module bug or buggy r.mapcalc expression can introduce a nan
into a grass raster map, and so we shouldn't sweep them under the carpet
as NULLs. They are distinct- mathematical null vs. spatial null.Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/
Hamish wrote:
IMO only a module bug or buggy r.mapcalc expression can introduce a nan
into a grass raster map, and so we shouldn't sweep them under the carpet
as NULLs. They are distinct- mathematical null vs. spatial null.
I disagree.
I can't think of a single case where a NaN result from a calculation
wouldn't be appropriately represented as null. Either we can make
every single module explicity test for NaN and convert it to a
specific bit pattern, or we can just extend the definition of null
from a specific NaN value to any NaN value.
Note that neither ANSI C nor IEEE-754 specify that a NaN arising from
a calculation will differ from the null value which GRASS uses.
IEEE-754 defines all values with an all-ones exponent and a non-zero
mantissa as NaN. Exactly which bit pattern you get is an arbitrary
choice made by the CPU designer. On x86, the usual NaN has the first
bit of the mantissa set an all other bits clear. But the all-ones bit
pattern which GRASS uses for null is a perfectly valid NaN value.
Using a specific bit pattern is just creating unnecessary work. E.g.
it means that we must always pass FCELL/DCELL values via pointers,
just so that we can test for nulls (the compiler and CPU aren't
required to preserve the exact bit pattern of a NaN value, only its
NaN-ness).
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Oct 8, 2008 at 1:45 AM, Hamish <hamish_b@yahoo.com> wrote:
Glynn:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
fwiw, I consider this a rare, but potentially very important change to
the raster engine.Markus:
> /me backport this?
Maybe.
Unless there are modules which genuinely need to distinguish GRASS
nulls from other NaNs,It can help in tracking down bugs, e.g. see the BUGS section of the
r.in.xyz man page.
OK, backported: r33752 We are still in 6.4-devel mode.
Markus
Markus Neteler wrote:
> Glynn:
>>>> Make G_is_[fd]_null_value() check for any NaN, not just all-ones
>
> fwiw, I consider this a rare, but potentially very important change to
> the raster engine.
>
> Markus:
>> > /me backport this?
Glynn:
>> Maybe.
>>
>> Unless there are modules which genuinely need to distinguish GRASS
>> nulls from other NaNs,
Hamish:
> It can help in tracking down bugs, e.g. see the BUGS section of the
> r.in.xyz man page.
Markus:
OK, backported: r33752 We are still in 6.4-devel mode.
um, I meant that as a reason NOT to backport it. Now it is less obvious
when nans are introduced by mistake.
but whatever..
Hamish
On Thu, Oct 9, 2008 at 12:38 AM, Hamish <hamish_b@yahoo.com> wrote:
Markus Neteler wrote:
> Glynn:
>>>> Make G_is_[fd]_null_value() check for any NaN, not just all-ones
>
> fwiw, I consider this a rare, but potentially very important change to
> the raster engine.
>
> Markus:
>> > /me backport this?Glynn:
>> Maybe.
>>
>> Unless there are modules which genuinely need to distinguish GRASS
>> nulls from other NaNs,Hamish:
> It can help in tracking down bugs, e.g. see the BUGS section of the
> r.in.xyz man page.Markus:
OK, backported: r33752 We are still in 6.4-devel mode.
um, I meant that as a reason NOT to backport it. Now it is less obvious
when nans are introduced by mistake.
Ah!
Feel free to revert. I am unable to judge this...
Markus