Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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 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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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, dec0 is ignored, dec0 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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
On 05/20/2013 01:46 PM, Glynn Clements wrote: 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)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.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. Hi Glynn, In case you haven't seen it, Markus Metz has implemented in trunk r56313 http://trac.osgeo.org/grass/changeset/56313 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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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 gl...@gclements.plus.comwrote: 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 gl...@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
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
Glynn Clements gl...@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, dec0 is ignored, dec0 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: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
Paulo van Breugel p.vanbreu...@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 gl...@gclements.plus.comwrote: 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 gl...@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: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
On Fri, May 17, 2013 at 5:13 PM, Paulo van Breugel p.vanbreu...@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)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.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 gl...@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 gl...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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.vanbreu...@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)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.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 gl...@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 gl...@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 -- 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: p...@life.ku.dk e-mail: p.vanbreu...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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.vanbreu...@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.k...@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)/(300797-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 gl...@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: rai...@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: rai...@krugs.de Skype: RMkrug pgp18ufkCqXo2.pgp Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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.vanbreu...@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.k...@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)/(300797-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 gl...@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: rai...@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: p...@life.ku.dk e-mail: p.vanbreu...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
Glynn Clements gl...@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: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[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)/(300797-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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
Paulo van Breugel p.vanbreu...@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)/(300797-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)/(300797-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: rai...@krugs.de Skype: RMkrug pgpxMycturHaI.pgp Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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.vanbreu...@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)/(300797-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)/(300797-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 -- 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: p...@life.ku.dk e-mail: p.vanbreu...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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)/(300797-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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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)/(300797-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 gl...@gclements.plus.com javascript:; ___ grass-dev mailing list grass-dev@lists.osgeo.org javascript:; 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: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
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.k...@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)/(300797-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 gl...@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: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
