[GRASS5] [bug #1372] (grass) r.mapcalc: strange multiplication bug

[Glynn Clements]

Request Tracker wrote:

> while working with r.mapcalc (in fact r.mapcalc new version)
> we came accross a strange multiplication error:
> 
> The idea was to multiply all values in
> plancS11.30m at Curvature
> with 100000. The result seems to be nonsense.

>  baez:insubri 171%r.info plancS11.30m at Curvature

>  |   Range of data:    min =  -466153.648586 max = 466153.648586              |

466153.648586 * 100000 = 46615364858.60001, which is 20 times the
range of a 32-bit integer (-2147483648 ... 2147483647).

> baez:insubri 172%r.mapcalc 'pippo2=int(plancS11.30m at Curvature*100000)'

This will wrap.

> Did we hit an upper/lower limit of CELL?

Yes.

> If so, r.mapcalc should refuse to write an output map.

So you want int() to detect overflow errors? That's easy enough. 
However, if you had performed the coercion to integer first, then
multiplied, i.e.:

	r.mapcalc 'pippo2=int(plancS11.30m at Curvature)*100000'

then the integer multiplication operator would have to trap the error. 
And that is pretty hard to do correctly and portably without a
substantial performance hit.

Note that the old r.mapcalc behaved in exactly the same way. As do the
integer arithmetic operators in most programming languages.

-- 
Glynn Clements <glynn.clements at virgin.net>