[GRASS-dev] Overflow warning in r.mapcalc calculation

Hi,

I am having trouble with the following computation, which gives me an overflow warning (“WARNING: Overflow occured in the calculation”).

r.mapcalc "A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite

whereby C is a map with values between 1 and 31000. It seems to be related to the size of the numbers (no warning if I divide C by 0.001), but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems to be correct. However, I rather avoid this warning, also because the warning message causes problems when running in batch from within R.

I am running GRASS 7.0 on Ubuntu 13.04 64 bit.

Best

Paulo

Paulo van Breugel <p.vanbreugel@gmail.com> writes:

Hi,

I am having trouble with the following computation, which gives me an overflow warning ("WARNING: Overflow occured in the
calculation").

oerflow usually means that the result of a calculation does not fit into
the variable type selected, i.e. is either smaller then the smallest
value which can be stored or larger then the largest value.

GRASS uses FCELL (float) and DCELL (double) varisbles, where double can
store a larger range (sorry - I don't have the actual values at hand).

You should be able to do the calculations by explicitely converting the
result to double by using the double() function:

UNTESTED:

  r.mapcalc "A = if(B==0, double( (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0 ), 1) " --overwrite

should work, although untested.It is possible, thet the conversion to
double needs to be made inside the calculation, depending where the
actual overflow occurs.

r.mapcalc "A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite

whereby C is a map with values between 1 and 31000. It seems to be related to the size of the numbers (no warning if I
divide C by 0.001), but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems to be correct. However, I rather avoid this
warning, also because the warning message causes problems when running in batch from within R.

Yes - overflow is a warning only, but *usually* results in wrong
results! I fell in that trap once and it took me some time to figure out
what was going on, as, if I remember correctly, no warning was issued
(GRASS 6.4?).

Cheers,

Rainer

I am running GRASS 7.0 on Ubuntu 13.04 64 bit.

Best

Paulo

_______________________________________________
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 : +33 - (0)9 58 10 27 44

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

email: Rainer@krugs.de

Skype: RMkrug

Hi Rainer,

Thanks a lot for your reply. The problem is indeed that the result of the calculation does not fit into the variable and your answer made me realize I had to take a closer look at what happens inside the formula. As it turns out, the problem lies in the following part of the formula:

round(C/0.0001)

The output of round() is an integer and c/0.0001 gives values that are larger then the maximum number for integer layers (which I presume is (2^31)-1). So I need to rethink the formula and the use of round.

Paulo

···

On 05/15/2013 03:51 PM, Rainer M. Krug wrote:

Paulo van Breugel [<p.vanbreugel@gmail.com>](mailto:p.vanbreugel@gmail.com) writes:

Hi,

I am having trouble with the following computation, which gives me an overflow warning ("WARNING: Overflow occured in the
calculation").

oerflow usually means that the result of a calculation does not fit into
the variable type selected, i.e. is either smaller then the smallest
value which can be stored or larger then the largest value.

GRASS uses FCELL (float) and DCELL (double) varisbles, where double can
store a larger range (sorry - I don't have the actual values at hand).

You should be able to do the calculations by explicitely converting the
result to double by using the double() function:

UNTESTED:

  r.mapcalc "A = if(B==0, double( (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0 ), 1) " --overwrite

should work, although untested.It is possible, thet the conversion to
double needs to be made inside the calculation, depending where the
actual overflow occurs.

r.mapcalc "A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite

whereby C is a map with values between 1 and 31000. It seems to be related to the size of the numbers (no warning if I
divide C by 0.001), but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems to be correct. However, I rather avoid this
warning, also because the warning message causes problems when running in batch from within R.

Yes - overflow is a warning only, but *usually* results in wrong
results! I fell in that trap once and it took me some time to figure out
what was going on, as, if I remember correctly, no warning was issued
(GRASS 6.4?).

Cheers,

Rainer

I am running GRASS 7.0 on Ubuntu 13.04 64 bit.

Best

Paulo

_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](http://lists.osgeo.org/mailman/listinfo/grass-dev)


-- 

Paulo van Breugel
Department of Geosciences and Natural Resource Management
Section of Forest, Nature and Biomass
University of Copenhagen

Rolighedsvej 23
1958 Frederiksberg C
Phone: +45 353-31646
Phone: +31 6 12189147
e-mail: [pvb@life.ku.dk](mailto:pvb@life.ku.dk)
e-mail: [p.vanbreugel@gmail.com](mailto:p.vanbreugel@gmail.com)

Paulo van Breugel wrote:

I am having trouble with the following computation, which gives me an
overflow warning ("WARNING: Overflow occured in the calculation").

r.mapcalc "A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite

whereby C is a map with values between 1 and 31000. It seems to be
related to the size of the numbers (no warning if I divide C by 0.001),
but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems
to be correct. However, I rather avoid this warning, also because the
warning message causes problems when running in batch from within R.

The round() function always returns an integer, regardless of its
argument types. Integers are always 32-bit, so the result is limited
to the range +/- 2147483647 (2^31-1).

--
Glynn Clements <glynn@gclements.plus.com>

On Wednesday, May 15, 2013, Glynn Clements wrote:

Paulo van Breugel wrote:

I am having trouble with the following computation, which gives me an
overflow warning (“WARNING: Overflow occured in the calculation”).

r.mapcalc “A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)” --overwrite

whereby C is a map with values between 1 and 31000. It seems to be
related to the size of the numbers (no warning if I divide C by 0.001),
but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems
to be correct. However, I rather avoid this warning, also because the
warning message causes problems when running in batch from within R.

The round() function always returns an integer, regardless of its
argument types. Integers are always 32-bit, so the result is limited
to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the integer range? Would be useful. Looking at the functions in r.mapcalc, I can’t think of a way of doing this?

Rainer


Glynn Clements glynn@gclements.plus.com


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

I would second that, it certainly would be handy to be able to round numbers outside the integer range and in addition, rounding with a specific number of decimal places, like e.g., the function round() in R. Is there a specific reason the round() function results in an integer?

Paulo

···

On Wed, May 15, 2013 at 9:20 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On Wednesday, May 15, 2013, Glynn Clements wrote:

Paulo van Breugel wrote:

I am having trouble with the following computation, which gives me an
overflow warning (“WARNING: Overflow occured in the calculation”).

r.mapcalc “A = if(B==0, (round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)” --overwrite

whereby C is a map with values between 1 and 31000. It seems to be
related to the size of the numbers (no warning if I divide C by 0.001),
but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems
to be correct. However, I rather avoid this warning, also because the
warning message causes problems when running in batch from within R.

The round() function always returns an integer, regardless of its
argument types. Integers are always 32-bit, so the result is limited
to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the integer range? Would be useful. Looking at the functions in r.mapcalc, I can’t think of a way of doing this?

Rainer


Glynn Clements glynn@gclements.plus.com


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

I just looked at the round function in xround.c, and it does not look to
complicated to modify round() to obtain have three more functions, aligned to the
R functions:

From the R help:
,----
| ‘ceiling’ takes a single numeric argument ‘x’ and returns a
| numeric vector containing the smallest integers not less than the
| corresponding elements of ‘x’.
|
| ‘floor’ takes a single numeric argument ‘x’ and returns a numeric
| vector containing the largest integers not greater than the
| corresponding elements of ‘x’.
|
| ‘trunc’ takes a single numeric argument ‘x’ and returns a numeric
| vector containing the integers formed by truncating the values in
| ‘x’ toward ‘0’.
`----

In addition, an additional argument could be added to the round()
function to round to the number of specified decimal places, so that it
is equivalent to your suggestion, Paulo.

From the R help:
,----
| ‘round’ rounds the values in its first argument to the specified
| number of decimal places (default 0).
`----

Unfortunately I don't have the experience in C and absolutely no time at
the moment to get into it.

Cheers,

Rainer

Paulo van Breugel <p.vanbreugel@gmail.com> writes:

I would second that, it certainly would be handy to be able to round
numbers outside the integer range and in addition, rounding with a specific
number of decimal places, like e.g., the function round() in R. Is there a
specific reason the round() function results in an integer?

Paulo

On Wed, May 15, 2013 at 9:20 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On Wednesday, May 15, 2013, Glynn Clements wrote:

Paulo van Breugel wrote:

> I am having trouble with the following computation, which gives me an
> overflow warning ("WARNING: Overflow occured in the calculation").
>
> r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite
>
>
> whereby C is a map with values between 1 and 31000. It seems to be
> related to the size of the numbers (no warning if I divide C by 0.001),
> but I am not clear what limit I am hitting here or how to avoid this.
>
> The warning does not stop the calculation, and the resulting map seems
> to be correct. However, I rather avoid this warning, also because the
> warning message causes problems when running in batch from within R.

The round() function always returns an integer, regardless of its
argument types. Integers are always 32-bit, so the result is limited
to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the
integer range? Would be useful. Looking at the functions in r.mapcalc, I
can't think of a way of doing this?

Rainer

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
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

--
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 : +33 - (0)9 58 10 27 44

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

email: Rainer@krugs.de

Skype: RMkrug

Thanks for that Rainer. I have no expertise in C too, but let me file a feature / enhancement request, perhaps somebody can pick this up.

Cheers,

Paulo

···

On 05/16/2013 09:38 AM, Rainer M. Krug wrote:

I just looked at the round function in xround.c, and it does not look to
complicated to modify round() to obtain have three more functions, aligned to the
R functions:

>From the R help:
,----
|      ‘ceiling’ takes a single numeric argument ‘x’ and returns a
|      numeric vector containing the smallest integers not less than the
|      corresponding elements of ‘x’.
| 
|      ‘floor’ takes a single numeric argument ‘x’ and returns a numeric
|      vector containing the largest integers not greater than the
|      corresponding elements of ‘x’.
| 
|      ‘trunc’ takes a single numeric argument ‘x’ and returns a numeric
|      vector containing the integers formed by truncating the values in
|      ‘x’ toward ‘0’.
`----

In addition, an additional argument could be added to the round()
function to round to the number of specified decimal places, so that it
is equivalent to your suggestion, Paulo.

>From the R help:     
,----
|      ‘round’ rounds the values in its first argument to the specified
|      number of decimal places (default 0).
`----

Unfortunately I don't have the experience in C and absolutely no time at
the moment to get into it. 

Cheers,

Rainer

Paulo van Breugel [<p.vanbreugel@gmail.com>](mailto:p.vanbreugel@gmail.com) writes:

I would second that, it certainly would be handy to be able to round
numbers outside the integer range and in addition, rounding with a specific
number of decimal places, like e.g., the function round() in R. Is there a
specific reason the round() function results in an integer?

Paulo

On Wed, May 15, 2013 at 9:20 PM, Rainer M Krug [<r.m.krug@gmail.com>](mailto:r.m.krug@gmail.com) wrote:

On Wednesday, May 15, 2013, Glynn Clements wrote:

Paulo van Breugel wrote:

I am having trouble with the following computation, which gives me an
overflow warning ("WARNING: Overflow occured in the calculation").

r.mapcalc "A = if(B==0,

(round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)" --overwrite

whereby C is a map with values between 1 and 31000. It seems to be
related to the size of the numbers (no warning if I divide C by 0.001),
but I am not clear what limit I am hitting here or how to avoid this.

The warning does not stop the calculation, and the resulting map seems
to be correct. However, I rather avoid this warning, also because the
warning message causes problems when running in batch from within R.

The round() function always returns an integer, regardless of its
argument types. Integers are always 32-bit, so the result is limited
to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the
integer range? Would be useful. Looking at the functions in r.mapcalc, I
can't think of a way of doing this?

Rainer

--
Glynn Clements [<glynn@gclements.plus.com>](mailto:glynn@gclements.plus.com)
_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](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](mailto:Rainer@krugs.de)

Skype:      RMkrug


-- 

Paulo van Breugel
Department of Geosciences and Natural Resource Management
Section of Forest, Nature and Biomass
University of Copenhagen

Rolighedsvej 23
1958 Frederiksberg C
Phone: +45 353-31646
Phone: +31 6 12189147
e-mail: [pvb@life.ku.dk](mailto:pvb@life.ku.dk)
e-mail: [p.vanbreugel@gmail.com](mailto:p.vanbreugel@gmail.com)

Rainer M Krug wrote:

> The round() function always returns an integer, regardless of its
> argument types. Integers are always 32-bit, so the result is limited
> to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the
integer range?

No.

Would be useful. Looking at the functions in r.mapcalc, I can't
think of a way of doing this?

outmap = eval(d = inmap % 1.0, dd = if(d < 0,d+1,d), inmap - dd + if(dd > 0.5,1,0))

The added complexity is because the % operator returns a negative
value for a negative numerator. Specifically, a % b = a - int(a/b)*b,
where conversion to an integer rounds toward zero.

It's not clear whether this behaviour is intentional or just how it
turned out. This is how C's % operator is defined for integer
arguments (for floating-point values, the fmod() library function
behaves similarly).

Also: r.mapcalc's % operator will fail if a/b overflows the range of
an integer. That should be fixed

I just looked at the round function in xround.c, and it does not look to
complicated to modify round() to obtain have three more functions, aligned to the
R functions:

One option is to modify round() to take a second argument (defaulting
to 1), and have it return the first argument rounded to the nearest
multiple of the second. The return type would be that of the second
argument, i.e. round(x,1) rounds to the nearest integer and returns an
integer, round(x,1.0) rounds to the nearest integer and returns a
float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
multiple of 0.001), etc.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements <glynn@gclements.plus.com> writes:

Rainer M Krug wrote:

> The round() function always returns an integer, regardless of its
> argument types. Integers are always 32-bit, so the result is limited
> to the range +/- 2147483647 (2^31-1).

True - but is there an equivalent function to round numbers outside the
integer range?

No.

Would be useful. Looking at the functions in r.mapcalc, I can't
think of a way of doing this?

outmap = eval(d = inmap % 1.0, dd = if(d < 0,d+1,d), inmap - dd + if(dd > 0.5,1,0))

The added complexity is because the % operator returns a negative
value for a negative numerator. Specifically, a % b = a - int(a/b)*b,
where conversion to an integer rounds toward zero.

It's not clear whether this behaviour is intentional or just how it
turned out. This is how C's % operator is defined for integer
arguments (for floating-point values, the fmod() library function
behaves similarly).

Also: r.mapcalc's % operator will fail if a/b overflows the range of
an integer. That should be fixed

I just looked at the round function in xround.c, and it does not look to
complicated to modify round() to obtain have three more functions, aligned to the
R functions:

One option is to modify round() to take a second argument (defaulting
to 1), and have it return the first argument rounded to the nearest
multiple of the second. The return type would be that of the second
argument, i.e. round(x,1) rounds to the nearest integer and returns an
integer, round(x,1.0) rounds to the nearest integer and returns a
float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
multiple of 0.001), etc.

Sounds like a sensible approach without adding to many new
functions. But I would actually split the two, i.e. have two more
arguments, where one specifies the type,
and the other one the number of decimals to round to, i.e.

round(x, 0, "I") would be the default, rounding to whole number and
return an integer

round(x, 0, "F") would round to the next whole number but return an
float and

round(x, 0, "D") would round to the next whole number ad return a
double.

round(x, 2, "I") would return an error, while

round(x, 2, "D") would return a double, rounded to two decimals.

Cheers,

Rainer

--
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 : +33 - (0)9 58 10 27 44

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

email: Rainer@krugs.de

Skype: RMkrug

Rainer M. Krug wrote:

> One option is to modify round() to take a second argument (defaulting
> to 1), and have it return the first argument rounded to the nearest
> multiple of the second. The return type would be that of the second
> argument, i.e. round(x,1) rounds to the nearest integer and returns an
> integer, round(x,1.0) rounds to the nearest integer and returns a
> float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
> multiple of 0.001), etc.

Sounds like a sensible approach without adding to many new
functions. But I would actually split the two, i.e. have two more
arguments, where one specifies the type,
and the other one the number of decimals to round to, i.e.

round(x, 0, "I") would be the default, rounding to whole number and
return an integer

That interface isn't possible. r.mapcalc doesn't have a string type,
and there's no way that a function's return type can depend upon the
value of a parameter.

--
Glynn Clements <glynn@gclements.plus.com>

Hi Glynn and Rainer

Happy to see this exchange of ideas. It would be great if this could be implemented. Do you think it is useful I make a feature request on the bug tracker (with link to this email thread) so the idea doesn’t get lost?

···

On Fri, May 17, 2013 at 4:38 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rainer M. Krug wrote:

One option is to modify round() to take a second argument (defaulting
to 1), and have it return the first argument rounded to the nearest
multiple of the second. The return type would be that of the second
argument, i.e. round(x,1) rounds to the nearest integer and returns an
integer, round(x,1.0) rounds to the nearest integer and returns a
float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
multiple of 0.001), etc.

Sounds like a sensible approach without adding to many new
functions. But I would actually split the two, i.e. have two more
arguments, where one specifies the type,
and the other one the number of decimals to round to, i.e.

round(x, 0, “I”) would be the default, rounding to whole number and
return an integer

That interface isn’t possible. r.mapcalc doesn’t have a string type,
and there’s no way that a function’s return type can depend upon the
value of a parameter.


Glynn Clements <glynn@gclements.plus.com>


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

Glynn Clements <glynn@gclements.plus.com> writes:

Rainer M. Krug wrote:

> One option is to modify round() to take a second argument (defaulting
> to 1), and have it return the first argument rounded to the nearest
> multiple of the second. The return type would be that of the second
> argument, i.e. round(x,1) rounds to the nearest integer and returns an
> integer, round(x,1.0) rounds to the nearest integer and returns a
> float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
> multiple of 0.001), etc.

Sounds like a sensible approach without adding to many new
functions. But I would actually split the two, i.e. have two more
arguments, where one specifies the type,
and the other one the number of decimals to round to, i.e.

round(x, 0, "I") would be the default, rounding to whole number and
return an integer

That interface isn't possible. r.mapcalc doesn't have a string type,
and there's no way that a function's return type can depend upon the
value of a parameter.

In this case I would suggest different functions, e.g.

round(x) - as it is now

roundI(x, dec) - round to integer, dec>0 is ignored, dec<0 as below

roundD(x, dec) - round to double, where dec is the number of decimals it
should be rounded to

roundF(x, dec) - round to float, where dec is the number of decimals it
should be rounded to

if dec is positive, it is the number of decimals, if negative the
... (no idea what it is called, but if it is -1, 111 is rounded to 110,
-2 111 is rounded to 100)

default from dec would be 0.

These different functions would also have the advantage of probably
being faster then one single function.

Cheers,

Rainer

--
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 : +33 - (0)9 58 10 27 44

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

email: Rainer@krugs.de

Skype: RMkrug

Paulo van Breugel <p.vanbreugel@gmail.com> writes:

Hi Glynn and Rainer

Happy to see this exchange of ideas. It would be great if this could be
implemented. Do you think it is useful I make a feature request on the bug
tracker (with link to this email thread) so the idea doesn't get lost?

Yes please - I think that would be useful.

Thanks,

Rainer

On Fri, May 17, 2013 at 4:38 PM, Glynn Clements <glynn@gclements.plus.com>wrote:

Rainer M. Krug wrote:

> > One option is to modify round() to take a second argument (defaulting
> > to 1), and have it return the first argument rounded to the nearest
> > multiple of the second. The return type would be that of the second
> > argument, i.e. round(x,1) rounds to the nearest integer and returns an
> > integer, round(x,1.0) rounds to the nearest integer and returns a
> > float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
> > multiple of 0.001), etc.
>
> Sounds like a sensible approach without adding to many new
> functions. But I would actually split the two, i.e. have two more
> arguments, where one specifies the type,
> and the other one the number of decimals to round to, i.e.
>
> round(x, 0, "I") would be the default, rounding to whole number and
> return an integer

That interface isn't possible. r.mapcalc doesn't have a string type,
and there's no way that a function's return type can depend upon the
value of a parameter.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

<#secure method=pgpmime mode=sign>

--
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 : +33 - (0)9 58 10 27 44

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

email: Rainer@krugs.de

Skype: RMkrug

On Fri, May 17, 2013 at 5:13 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:

Hi Glynn and Rainer

Happy to see this exchange of ideas. It would be great if this could be
implemented. Do you think it is useful I make a feature request on the bug
tracker (with link to this email thread) so the idea doesn't get lost?

Instead of

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)"
--overwrite

try

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902.0)/(3007966667.0-1175699902.0) *100.0, 1)"
--overwrite

or better with whitespaces

r.mapcalc "A = if(B == 0, (round(C / 0.0001) - 1175699902.0) /
(3007966667.0 - 1175699902.0) * 100.0, 1)" --overwrite

adding .0 to numbers forces all calculations to be done with floating
point double precision

Markus M

On Fri, May 17, 2013 at 4:38 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:

Rainer M. Krug wrote:

> > One option is to modify round() to take a second argument (defaulting
> > to 1), and have it return the first argument rounded to the nearest
> > multiple of the second. The return type would be that of the second
> > argument, i.e. round(x,1) rounds to the nearest integer and returns an
> > integer, round(x,1.0) rounds to the nearest integer and returns a
> > float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
> > multiple of 0.001), etc.
>
> Sounds like a sensible approach without adding to many new
> functions. But I would actually split the two, i.e. have two more
> arguments, where one specifies the type,
> and the other one the number of decimals to round to, i.e.
>
> round(x, 0, "I") would be the default, rounding to whole number and
> return an integer

That interface isn't possible. r.mapcalc doesn't have a string type,
and there's no way that a function's return type can depend upon the
value of a parameter.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Thanks Markus,

That is certainly a good suggestion. The problem however remains I think with the part

round(C / 0.0001)

If C/0.0001 > 2^31, i.e., larger then the maximum possible integer, there will be an error.

The white spaces, is that for another reason then being clearer?

Cheers,

Paulo

···

On 05/17/2013 10:57 PM, Markus Metz wrote:

On Fri, May 17, 2013 at 5:13 PM, Paulo van Breugel
[<p.vanbreugel@gmail.com>](mailto:p.vanbreugel@gmail.com) wrote:

Hi Glynn and Rainer

Happy to see this exchange of ideas. It would be great if this could be
implemented. Do you think it is useful I make a feature request on the bug
tracker (with link to this email thread) so the idea doesn't get lost?

Instead of

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)"
--overwrite

try

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902.0)/(3007966667.0-1175699902.0) *100.0, 1)"
--overwrite

or better with whitespaces

r.mapcalc "A = if(B == 0, (round(C / 0.0001) - 1175699902.0) /
(3007966667.0 - 1175699902.0) * 100.0, 1)" --overwrite

adding .0 to numbers forces all calculations to be done with  floating
point double precision

Markus M


On Fri, May 17, 2013 at 4:38 PM, Glynn Clements [<glynn@gclements.plus.com>](mailto:glynn@gclements.plus.com)
wrote:

Rainer M. Krug wrote:

One option is to modify round() to take a second argument (defaulting
to 1), and have it return the first argument rounded to the nearest
multiple of the second. The return type would be that of the second
argument, i.e. round(x,1) rounds to the nearest integer and returns an
integer, round(x,1.0) rounds to the nearest integer and returns a
float, round(x,1e-3) would round to 3 decimal places (i.e. the nearest
multiple of 0.001), etc.

Sounds like a sensible approach without adding to many new
functions. But I would actually split the two, i.e. have two more
arguments, where one specifies the type,
and the other one the number of decimals to round to, i.e.

round(x, 0, "I") would be the default, rounding to whole number and
return an integer

That interface isn't possible. r.mapcalc doesn't have a string type,
and there's no way that a function's return type can depend upon the
value of a parameter.

--
Glynn Clements [<glynn@gclements.plus.com>](mailto:glynn@gclements.plus.com)
_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](http://lists.osgeo.org/mailman/listinfo/grass-dev)


_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](http://lists.osgeo.org/mailman/listinfo/grass-dev)

-- 

Paulo van Breugel
Department of Geosciences and Natural Resource Management
Section of Forest, Nature and Biomass
University of Copenhagen

Rolighedsvej 23
1958 Frederiksberg C
Phone: +45 353-31646
Phone: +31 6 12189147
e-mail: [pvb@life.ku.dk](mailto:pvb@life.ku.dk)
e-mail: [p.vanbreugel@gmail.com](mailto:p.vanbreugel@gmail.com)

Markus Metz wrote:

> Happy to see this exchange of ideas. It would be great if this could be
> implemented. Do you think it is useful I make a feature request on the bug
> tracker (with link to this email thread) so the idea doesn't get lost?

Instead of

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902)/(3007966667-1175699902) *100.0, 1)"
--overwrite

try

r.mapcalc "A = if(B==0,
(round(C/0.0001)-1175699902.0)/(3007966667.0-1175699902.0) *100.0, 1)"
--overwrite

or better with whitespaces

r.mapcalc "A = if(B == 0, (round(C / 0.0001) - 1175699902.0) /
(3007966667.0 - 1175699902.0) * 100.0, 1)" --overwrite

adding .0 to numbers forces all calculations to be done with floating
point double precision

That won't help; the problem is that round() returns an integer.

It wouldn't be particularly hard to change it so that the return type
is the same as the argument type, but that might break existing
scripts.

--
Glynn Clements <glynn@gclements.plus.com>

Rainer M. Krug wrote:

>> Sounds like a sensible approach without adding to many new
>> functions. But I would actually split the two, i.e. have two more
>> arguments, where one specifies the type,
>> and the other one the number of decimals to round to, i.e.
>>
>> round(x, 0, "I") would be the default, rounding to whole number and
>> return an integer
>
> That interface isn't possible. r.mapcalc doesn't have a string type,
> and there's no way that a function's return type can depend upon the
> value of a parameter.

In this case I would suggest different functions, e.g.

round(x) - as it is now

roundI(x, dec) - round to integer, dec>0 is ignored, dec<0 as below

roundD(x, dec) - round to double, where dec is the number of decimals it
should be rounded to

roundF(x, dec) - round to float, where dec is the number of decimals it
should be rounded to

if dec is positive, it is the number of decimals, if negative the
... (no idea what it is called, but if it is -1, 111 is rounded to 110,
-2 111 is rounded to 100)

default from dec would be 0.

These different functions would also have the advantage of probably
being faster then one single function.

1. I wouldn't bother with separate functions, but instead use the type
of the second argument to determine the return type, i.e.

  round(x, 1) -> CELL
  round(x, 1.0f) -> FCELL
  round(x, 1.0) -> DCELL

The value of the second argument can be ignored, or it can be used for
other purposes.

2. Rounding to a given number of decimals is unnecessarily limiting.
The algorithm for generalised rounding is essentially:

  roundTo(x, k) = round(x / k) * k.

Rounding to N decimal places is just a case of using k=1/10^N. If you
allow k to be specified directly, then you can round to arbitrary
steps (e.g. k=5 would round to the nearest multiple of 5, etc).

3. However: there's a slight problem with doing it that way: 0.1 isn't
exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it
would be more accurate to use:

  roundTo(x, k) = round(x * k) / k

where k is the reciprocal of the step, so k=10^N to round to N decimal
places (or k=2 to round to 1/2).

The downside is that the interface is less useful if you want to round
to something other than a fixed number of decimal places. E.g. if you
wanted to round to the nearest multiple of 45 degrees, you'd need to
use k=1.0/45, which isn't exactly representable.

--
Glynn Clements <glynn@gclements.plus.com>

Hi Glynn,

In case you haven’t seen it, Markus Metz has implemented in trunk r56313 the option to have the same raster type as output of round() as the input type, see ticket 1976 (http://trac.osgeo.org/grass/ticket/).

I sure hope it does not brake existing scripts, as this is a very useful enhancement I think.

Paulo van Breugel wrote:

In case you haven't seen it, Markus Metz has implemented in trunk r56313
<http://trac.osgeo.org/grass/changeset/56313&gt; the option to have the
same raster type as output of round() as the input type, see ticket 1976
(http://trac.osgeo.org/grass/ticket/).

I've seen it. Don't rely upon that behaviour, as I intend to change
it: http://trac.osgeo.org/grass/ticket/1976#comment:4

--
Glynn Clements <glynn@gclements.plus.com>