[GRASS-dev] r.mapcal rand() strangeness

Glynn Clements glynn at gclements.plus.com
Sun Feb 24 12:33:54 EST 2008


Maciej Sieczka wrote:

> >>> $ r.mapcalc 'map=rand(-2147483648,2147483647)'
> 
> >>     res[i] = (lo == hi) ? lo : lo + x % (hi - lo);
> >>
> >> The expression (hi - lo) is overflowing the range of a signed integer.
> 
> Are all GRASS modules limited to Int32, ie. -2147483648 to 214748364? I 
> can see r.mapcalc silently forces 214748364 for anything bigger...

The limits are -214748367 to 214748367 inclusive.

If you aren't seeing anything larger than 214748364, it may just be
that you aren't taking enough samples. mrand48() etc use a 48-bit
state, so even taking 2^32 samples doesn't guarantee that you will see
all 2^32 possible values.

> >> The wrapping can be fixed by adding casts, i.e.:
> >>
> >>     res[i] = (lo == hi) ? lo : lo + (unsigned) x % (unsigned) (hi - lo);
> >>
> >> The 31-bit limitation can be fixed by replacing lrand48() with
> >> mrand48(), which covers the full (signed) 32-bit range.
> >>
> >> The attached patch appears to work.
> 
> > Will you apply it?
> 
> I forgot to write I tested it and confirm it seems OK.

I've committed it.

> >> One final point: -2^31 (= 0x80000000 = -2147483648) is the null value
> >> for the CELL type, so you'll never see that value in a map.
> 
> > BTW, what are the NULL value for double and float?

The FP nulls are the all-ones bit patterns. These corresponds to NaN
according to the IEEE-754 formats, although it isn't the "default" NaN
pattern generated by most architectures (which is usually 7fc00000 or
ffc00000 for float and 7ff8000000000000 or fff8000000000000 for
double, i.e. an all-ones exponent, the top-bit of the mantissa set,
and either sign).

So far as arithmetic is concerned, any value with an all-ones exponent
and a non-zero mantissa is treated as NaN. But the GRASS
G_is_[fd]_null_value() functions only consider the all-ones bit
pattern to be null. I intend to change this in 7.x so that all FP NaN
values are treated as null. This will mean that code which can
generate NaNs doesn't have to explicitly convert them to the GRASS
null value.

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


More information about the grass-dev mailing list