[GRASS-dev] r.mapcalc 32-bit ceiling

[Glynn Clements]

Rainer M Krug wrote:

> > I ran into an unexpected issue (to me, at least) with r.mapcalc:
> > I was multiplying and dividing by some pretty big scalars, and one of
> > those was greater than a 32-bit signed value (so >2**31). What mapcalc
> > did was to reduce that value to 2**31 and carry on with operations.
> > There was no warning, and I didn't find any information about this on
> > the r.mapcalc help page, so I just wanted to alert (or possibly
> > remind) the list that this exists and note that (as a non-developer)
> > it took me a while to figure out that this was a problem. If there is
> > an easy way to throw an error instead of silently hitting a ceiling,
> > or this would be important enough to put on the manual webpage, I
> > think it would be helpful, and certainly would have saved me a ton of
> > time.
> 
> I ran into the same issue when I was using integers - I solved it by
> converting the raster to double. But I agree with Andy: I think GRASS
> should throw an error when the rollover occurs, or use a dedicated value in
> this cell, so that one can check afterwards. Thinking about it: an error is
> asked for, as something went wrong.

There can be a significant performance hit for doing this. Checking
whether the result of an addition overflowed is actually more
expensive than the addition itself. Checking whether a multiplication
overflowed can be even worse (particularly if you don't have a 64-bit
integer type available).

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