Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
On Thu, Oct 9, 2008 at 12:38 AM, Hamish [EMAIL PROTECTED] 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
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 [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
On Wed, Oct 8, 2008 at 1:45 AM, Hamish [EMAIL PROTECTED] 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
Glynn, On Tue, Oct 7, 2008 at 12:02 PM, [EMAIL PROTECTED] 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? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
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 [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
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
Re: [GRASS-dev] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
Wouldn't it be interesting then to have G_is_[fd]_nan_value()? 2008/10/8 Hamish [EMAIL PROTECTED]: 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/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
