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

GRASS GIS GRASS GIS developer
1

Hi Grass-dev,

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.

Thanks, and happy Thanksgiving to those in the USA!

Andy

2

On Fri, Nov 25, 2011 at 4:31 AM, Andy Wickert <andrewwickert@gmail.com> wrote:

Hi Grass-dev,

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 >231). What mapcalc
did was to reduce that value to 231 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.

Cheers,

Rainer

Thanks, and happy Thanksgiving to those in the USA!

Andy

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

3

Thanks for the tip, Rainer! I'll convert to double as a workaround.
Andy

4

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@gclements.plus.com>

5

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@gclements.plus.com>

Hm. If that's a debilitating issue, perhaps the overflow check could
be triggered by a flag (e.g., if the user thinks there may be a
problem) or (easier) some information on typing and overflow could be
placed on the man page.

Andy

6

On Sun, Nov 27, 2011 at 4:57 AM, Andy Wickert <andrewwickert@gmail.com> wrote:

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@gclements.plus.com>

Hm. If that’s a debilitating issue,

I agree. And it should actualy not happen or at least a warning should be given.

perhaps the overflow check could
be triggered by a flag (e.g., if the user thinks there may be a
problem)

That would be the minimum - I would even opt for an environmental variable GRASS_CHECK_OVERFLOW which provides overflow checking globally for all functions which can produce an overflow. r.mapcalc would be the obvious candidate, but there are others which can produce overflow and which should be checking for overflow as well.

GRASS_CHECK_OVERFLOW could have three values:

  • unset or “NO” (default): do not check for overflow (the default as it is now)
  • “error”: check and raise an error if overflow occurs
  • “warning”: check and produce a warning if overflow occurs.

or (easier) some information on typing and overflow could be
placed on the man page.

I don’t think that is enough - I solved the problem on my side by using double instead of integer, but it took me some time to figure out why my results were wrong. So: Yes, there should definitely be a warning in the manual (highlighted and in Bold so that even I would have seen it…), but the option to check and raise an error on overflow should be provided.

And as an environmental variable, it could be used by all modules.

Cheers,

Rainer

Andy

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug