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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
