[GRASS-dev] Re: [GRASS GIS] #392: backport G_is_c_null_value() to devbr6

[Glynn Clements]

Hamish wrote:

> MN:
> > > Since there are no comments there does not seem to be a bug
> > > in GRASS 6.x.
> > > So: if it ain't broken, don't fix it.
> PK: 
> > That's true; I agree. It's definitely not a bug; just a change for 
> > potential future compatibility with invalid raster files so
> > we don't need  it now.
> 
> 
> just to note that currently FCELL,DCELL checks do it the "new way" of
> if (x != x), while CELL still checks it the old way. ie F,D got
> backported but CELL didn't.
> 
> the commit log said check if both all 0s

All-ones. All-zeroes is (positive) zero.

> and if nan, but the check is just
> for nan. Is it the case that for all modern systems (IEEE FP's) the two
> are identical?

According to IEEE-754, any value where the exponent is all-ones and
the mantissa is non-zero is a NaN. That includes the all-ones pattern,
but isn't limited to it.

However, you can't guarantee that operations such as assignment or
argument-passing preserve the exact bit pattern. If you pass a NaN as
a function argument, the parameter variable will be NaN, but it might
not be the exact same bit pattern.

Also, you can't guarantee that NaNs generated by the FPU (e.g. 0.0/0)
*won't* be the all-ones bit pattern, i.e. you can't guarantee the
ability to distinguish between "GRASS nulls" and NaNs arising from FP
arithmetic.

Finally, if there's an architecture where the all-ones pattern isn't
NaN, then it's a defined value, which means that it can arise as a
result of normal FP arithmetic.

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