hi!
I suppose I found a bug in r.mapcalc
(but I hope I didn't :))
I'm still in Grass 5.03 so if this is already fixed in newer release please
forgive me for taking you time
the problem: when working with really big numbers r.mapcalc lies if you
don't add an ".0" after a number you input:
WRONG result when without the ".0" following the "636287352795314688":
r.mapcalc
'187bf256=(187bf-220330.1520377753)/(636287352795314688-220330.1520377753)*2
55'
r.univar 187bf256
Number of cells (excluding NULL cells): 3256397
Minimum: 0
Maximum: 75562821610.9638366699
Range: 7.55628e+10
Arithmetic mean: 2.9251e+09
Variance: 2.61519e+19
Standard deviation: 5.1139e+09
Variation coefficient: 174.828 %
FINE when the ".0" is added:
r.mapcalc
'187bf256=(187bf-220330.1520377753)/(636287352795314688.0-220330.1520377753)
*255'
r.univar 187bf256
Number of cells (excluding NULL cells): 3256397
Minimum: 0
Maximum: 255
Range: 255
Arithmetic mean: 9.87126
Variance: 297.83
Standard deviation: 17.2577
Variation coefficient: 174.828 %
FYI: the '187bf' raster is DCELL
another strange example:
r.mapcalc
'187bf256=round((187bf-220330.1520377753)/(636287352795314688-220330.1520377
753)*255)'
100%
NOTE: overflow occured in the calculation
r.info 187bf256 -r
min=0
max=2147479019
what may it be?
Maciek
Maciek Sieczka wrote:
I suppose I found a bug in r.mapcalc
(but I hope I didn't :))
I'm still in Grass 5.03 so if this is already fixed in newer release please
forgive me for taking you time
the problem: when working with really big numbers r.mapcalc lies if you
don't add an ".0" after a number you input:
A string of digits without a decimal point is interpreted as an
integer, which has a range of -2147483648 to 2147483647.
If you add ".0" to the end (or even just "."), it will be interpreted
as a double-precision (64-bit) floating point value, which has a range
of approximately +/- 1.8e+308 with a precision of around 15 decimal
digits.
Also, you can specify a single-precision (32-bit) floating point value
(range of approximately +/- 3.4e+38, with a precision of around 6
decimal digits) by appending "f" or "F" to the value, e.g. "1.2f".
This is intentional behaviour. If you wish to specify a floating-point
constant, you have to include the decimal point.
--
Glynn Clements <glynn.clements@virgin.net>
A string of digits without a decimal point is interpreted as an
integer, which has a range of -2147483648 to 2147483647.
If you add ".0" to the end (or even just "."), it will be interpreted
as a double-precision (64-bit) floating point value, which has a range
of approximately +/- 1.8e+308 with a precision of around 15 decimal
digits.
Also, you can specify a single-precision (32-bit) floating point value
(range of approximately +/- 3.4e+38, with a precision of around 6
decimal digits) by appending "f" or "F" to the value, e.g. "1.2f".
This is intentional behaviour. If you wish to specify a floating-point
constant, you have to include the decimal point.
I'm sure there are reasons that it's "intentional" but also it's not
intuitive for me and I believe for dozens like me. This may eventually get
someone into troubles, don't you agree? Is this issue explained somewhere
in the Grass manual? I can't find it. I suggest it should be - IN CAPITALS.
Maciek
Maciek Sieczka wrote:
> A string of digits without a decimal point is interpreted as an
> integer, which has a range of -2147483648 to 2147483647.
>
> If you add ".0" to the end (or even just "."), it will be interpreted
> as a double-precision (64-bit) floating point value, which has a range
> of approximately +/- 1.8e+308 with a precision of around 15 decimal
> digits.
>
> Also, you can specify a single-precision (32-bit) floating point value
> (range of approximately +/- 3.4e+38, with a precision of around 6
> decimal digits) by appending "f" or "F" to the value, e.g. "1.2f".
>
> This is intentional behaviour. If you wish to specify a floating-point
> constant, you have to include the decimal point.
I'm sure there are reasons that it's "intentional" but also it's not
intuitive for me and I believe for dozens like me.
The syntax and semantics of r.mapcalc expressions significantly
resemble those of the C language, which is probably the most
widely-known programming language. I would guess that this was
intentional.
I doubt that any syntax will be intuitive for everyone. In particular,
I suspect that people who only know one programming language will have
a tendency to assume similarities between that language and r.mapcalc.
This may eventually get
someone into troubles, don't you agree? Is this issue explained somewhere
in the Grass manual? I can't find it. I suggest it should be - IN CAPITALS.
The r.mapcalc manpage says:
: FLOATING POINT VALUES IN THE EXPRESSION
: Floating point numbers are allowed in the expression. A
: floating point number is a number which contains a decimal
: point:
:
: 2.3 12. .81
Ultimately, the r.mapcalc manpage should include a full, inductive
definition of the language, rather than a number of ad-hoc statements
regarding specific aspects. Any volunteers?
--
Glynn Clements <glynn.clements@virgin.net>
The syntax and semantics of r.mapcalc expressions significantly
resemble those of the C language, which is probably the most
widely-known programming language. I would guess that this was
intentional.
...
The r.mapcalc manpage says:
...
sorry, I should have read the r.mapcalc man more carefully, some of my
problems are explained there
propably I was too tired to see it
anyway - I just assumed that numbers are numbers i.e 1 and 1.0 are exactly
the same like they told me at school
stupid me
but not everybody knows C and it's conventions
many don't know any programming language
and the fraction of such Grass users will encrease as Grass developes and
becomes more popular
so either there is a complete, up to date, manual and tutorial or more,
propably ridicolous from your point of view, questions may arrise
in general beware - I may ask you something again in the close future 
Maciek
Maciek Sieczka wrote:
> The syntax and semantics of r.mapcalc expressions significantly
> resemble those of the C language, which is probably the most
> widely-known programming language. I would guess that this was
> intentional.
>...
> The r.mapcalc manpage says:
> ...
sorry, I should have read the r.mapcalc man more carefully, some of my
problems are explained there
propably I was too tired to see it
anyway - I just assumed that numbers are numbers i.e 1 and 1.0 are exactly
the same like they told me at school
stupid me
but not everybody knows C and it's conventions
many don't know any programming language
Well, r.mapcalc is essentially a programming language, albeit a fairly
simple one. Although, we should really provide a more detailed
explanation for users with no prior programming experience.
OTOH, the distinction between integers and real (or floating-point)
numbers isn't restricted to C. Most programming languages make this
distinction, as does mathematics ("discrete" mathematics versus the
rest of it).
Also, the convention that "1" is an integer while "1.0" is a real is
almost as common. Some languages would treat "1.0" as a real but
determine whether "1" is integer or real based upon context, although,
in practice, this can create as many problems as it solves (I'll leave
it at that; discussions among programmers as to whether context
dependence is good or bad often degenerate into a flame-war).
--
Glynn Clements <glynn.clements@virgin.net>