Thu, Oct 24 2002
17:49:20
|
|
Request created by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 24 Oct 2002 17:49:15 +0200
|
From |
Markus Neteler <neteler@itc.it>
|
To |
grass-bugs@intevation.de, Steno Fontanari <fontana@itc.it>
|
Subject |
r.mapcalc: strange multiplication bug
|
Message-ID |
<20021024174915.A24931@itc.it>
|
References |
<20021024174325.A6071@baez.itc.it>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
User-Agent |
Mutt/1.2.5.1i
|
In-Reply-To |
<20021024174325.A6071@baez.itc.it>; from fontana@itc.it on Thu, Oct 24, 2002 at 05:43:25PM +0200
|
X-Spam-Status |
No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41
|
X-Spam-Level |
|
Hi,
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@Curvature
with 100000. The result seems to be nonsense.
On Thu, Oct 24, 2002 at 05:43:25PM +0200, Steno Fontanari wrote:
baez:insubri 171%r.info plancS11.30m@Curvature
+----------------------------------------------------------------------------+
| Layer: plancS11.30m Date: Wed Jan 30 16:58:19 2002
|
| Type of Map: raster Number of Categories: 255
|
[...]
| Data Type: DCELL
|
| Rows: 3251
|
| Columns: 3871
|
| Total Cells: 12584621
|
| Projection: Transverse Mercator (zone 0)
|
| N: 5157109 S: 5059581 Res: 29.9993848
|
| E: 1728648 W: 1612512 Res: 30.00154999
|
| Range of data: min = -466153.648586 max = 466153.648586
|
|
|
| Data Source:
|
|
|
| Data Description:
|
| generated by r.param.scale
|
+----------------------------------------------------------------------------+
baez:insubri 172%r.mapcalc 'pippo2=int(plancS11.30m@Curvature*100000)'
baez:insubri 172%r.support -r pippo2
Updating the stats for [pippo2]
baez:insubri 173%r.info pippo2
+----------------------------------------------------------------------------+
| Layer: pippo2 Date: Thu Oct 24 17:26:50 2002
|
| Mapset: erdemolo Login of Creator: fontana
|
| Location: pat
|
| DataBase: /mpa_gdata/ssi/BIO/GRASS_DATA/data
|
| Title: ( pippo2 )
|
|----------------------------------------------------------------------------|
|
|
| Type of Map: raster Number of Categories: 1082618906
|
| Data Type: CELL
|
| Rows: 3251
|
| Columns: 3871
|
| Total Cells: 12584621
|
| Projection: Transverse Mercator (zone 0)
|
| N: 5157109 S: 5059581 Res: 29.9993848
|
| E: 1728648 W: 1612512 Res: 30.00154999
|
| Range of data: min = -1082618906 max = 1082618906
|
|
|
| Data Source:
|
| Data Description:
|
| generated by r.mapcalc
|
|
|
+----------------------------------------------------------------------------+
Did we hit an upper/lower limit of CELL?
If so, r.mapcalc should refuse to write an output map.
Markus
|
|
Thu, Oct 24 2002
17:56:53
|
|
Mail sent by guest
|
|
Just an update: Without int() it works.
See below.
With round() it also fails.
r.mapcalc 'pippo2=100000 * glomm'
pippo2 = (mul(double(100000),glomm[0,0]))
r.info pippo2%
100%
baez:insubri 195%r.info pippo2
+---------------------------------------------------------------------------
-+
| Layer: pippo2 Date: Thu Oct 24 17:53:34 2002
|
| Mapset: erdemolo Login of Creator: fontana
|
| Location: pat
|
| DataBase: /mpa_gdata/ssi/BIO/GRASS_DATA/data
|
| Title: ( pippo2 )
|
|---------------------------------------------------------------------------
-|
|
|
| Type of Map: raster Number of Categories: 255
|
| Data Type: DCELL
|
| Rows: 3251
|
| Columns: 3871
|
| Total Cells: 12584621
|
| Projection: Transverse Mercator (zone 0)
|
| N: 5157109 S: 5059581 Res: 29.9993848
|
| E: 1728648 W: 1612512 Res: 30.00154999
|
| Range of data: min = -46615364858.646423 max = 46615364858.646423
|
|
|
| Data Source:
|
|
|
|
|
|
|
| Data Description:
|
| generated by r.mapcalc
|
|
|
|
|
+---------------------------------------------------------------------------
-+
|
|
Thu, Oct 24 2002
17:58:23
|
|
User changed to fontana@itc.it,neteler@itc.it by mneteler
|
|
Fri, Oct 25 2002
00:30:08
|
|
Comments added by guest
|
|
On a typical 32bit machine:
limits.h
...
#define INT_MAX 2147483647
...
Therefore,
455153 * 100000 = 4551530000
results in integer overflow since the value can not be
represented in an int.
|
|
Fri, Oct 25 2002
10:10:05
|
|
Comments added by guest
|
|
Thanks for the hint. But r.mapcalc should refuse to
write nonsense maps (so we need to add an error based
on limit.h values)
Markus
|
|
Fri, Oct 25 2002
12:37:17
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<15801.6949.799257.581685@cerise.nosuchdomain.co.uk>
|
Date |
Fri, 25 Oct 2002 11:21:25 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1372] (grass) r.mapcalc: strange multiplication bug
|
In-Reply-To |
<20021024154920.5624E13ABE@lists.intevation.de>
|
References |
<20021024154920.5624E13ABE@lists.intevation.de>
|
X-Mailer |
VM 6.94 under 21.4 (patch 9) "Informed Management" XEmacs Lucid
|
X-Spam-Status |
No, hits=-11.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41
|
X-Spam-Level |
|
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@Curvature
> with 100000. The result seems to be nonsense.
> baez:insubri 171%r.info plancS11.30m@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@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@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@virgin.net>
|
|
Wed, Jan 22 2003
10:52:42
|
|
Mail sent by mneteler
|
|
... so no change is expected...
M.
|
|
Wed, Jan 22 2003
10:52:48
|
|
Status changed to resolved by mneteler
|
|