Re: [GRASS-user] Problem with r. mapcalc
Hi Giuseppe, On Tue, Mar 2, 2021 at 12:20 AM Giuseppe Amatulli wrote: > > Probably also a warning message will be good in the > r.mapcalc > r.out.gdal > when using FCELL (Float32) and overpassing the -16777216 to 16777216. > > Indeed, I didn't know there was such a numerical limit - so I'm wondering how > many times I have overpassed :-( Please open a ticket with an (ideally based on the North Carolina sample dataset) example at https://github.com/OSGeo/grass/issues (here it gets easily lost) thanks, Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Probably also a warning message will be good in the r.mapcalc r.out.gdal when using FCELL (Float32) and overpassing the -16777216 to 16777216. Indeed, I didn't know there was such a numerical limit - so I'm wondering how many times I have overpassed :-( Best Giuseppe On Sun, 28 Feb 2021 at 12:38, Veronica Andreo wrote: > Would you mind adding them and creating a PR, Nikos?? > That'd be great :) > > > El dom, 28 feb 2021 a las 10:22, escribió: > >> I think an overview table, like https://gitlab.com/-/snippets/2083412, >> should be part of both the raster introduction text and the manual of >> r.mapcalc. >> >> >> Thank you, Nikos >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-user >> > -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Would you mind adding them and creating a PR, Nikos?? That'd be great :) El dom, 28 feb 2021 a las 10:22, escribió: > I think an overview table, like https://gitlab.com/-/snippets/2083412, > should be part of both the raster introduction text and the manual of > r.mapcalc. > > > Thank you, Nikos > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
I think an overview table, like https://gitlab.com/-/snippets/2083412, should be part of both the raster introduction text and the manual of r.mapcalc. Thank you, Nikos___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Wiki updated!! https://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Raster_management https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics I hope that users will notice the range-bound of Folat32 to be from -16777216 to 16777216. Thanks Again Best Giuseppe On Fri, 26 Feb 2021 at 05:18, Markus Neteler wrote: > On Fri, Feb 26, 2021 at 2:20 AM Giuseppe Amatulli > wrote: > > > > Sorry, my wrong conclusion > > Single-precision floating-point variables are able to represent integers > between [-16777216, 16777216] > > maybe better to report in the r.out.gdal data type table > > FWIW: We have some info about raster precision and semantics here: > > https://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Raster_management > https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics > > (@All) Please expand the Wiki pages as needed. > > Markus > -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
On Fri, Feb 26, 2021 at 2:20 AM Giuseppe Amatulli wrote: > > Sorry, my wrong conclusion > Single-precision floating-point variables are able to represent integers > between [-16777216, 16777216] > maybe better to report in the r.out.gdal data type table FWIW: We have some info about raster precision and semantics here: https://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Raster_management https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics (@All) Please expand the Wiki pages as needed. Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Sorry, my wrong conclusion Single-precision floating-point variables are able to represent integers between [-16777216, 16777216] maybe better to report in the r.out.gdal data type table On Thu, 25 Feb 2021 at 12:20, Giuseppe Amatulli wrote: > Thanks to both of you!! > Now I got it! So the > Float32, CFloat32 -3.4E38 3.4E38 range identify the maximum number > of characters in the binary format and not in the decimal format - correct? > So even if 3024784769025 fit as a decimal number in -3.4E38 3.4E38 does > not fit as binary - correct? > ...this one I did not know... I spent a few days on this. > > yes r.info gives the scientific format so it will be nice to have also > the long decimal number.. .to spot this kind of errors. > Giuseppe > > > > On Thu, 25 Feb 2021 at 11:29, Maris Nartiss wrote: > >> Markus, output of r.univar and r.info both can have scientific >> notation in their range outputs. >> >> Giuseppe, at least on my system r.mapcalc for floating point >> expressions (if one of operands is floating point) defaults to double >> (stored as DCELL). Still to be safe you can convert one of operands >> (e.g. input map with ints) to double with double() as Markus already >> pointed out. >> >> Good luck, >> Māris. >> > > > -- > Giuseppe Amatulli, Ph.D. > > Research scientist at > School of the Environment > Yale University > New Haven, CT, USA - 06511 > Tweeter: @BigDataEcology > Teaching: http://spatial-ecology.net > Work: https://environment.yale.edu/profile/giuseppe-amatulli/ > > -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Thanks to both of you!! Now I got it! So the Float32, CFloat32 -3.4E38 3.4E38 range identify the maximum number of characters in the binary format and not in the decimal format - correct? So even if 3024784769025 fit as a decimal number in -3.4E38 3.4E38 does not fit as binary - correct? ...this one I did not know... I spent a few days on this. yes r.info gives the scientific format so it will be nice to have also the long decimal number.. .to spot this kind of errors. Giuseppe On Thu, 25 Feb 2021 at 11:29, Maris Nartiss wrote: > Markus, output of r.univar and r.info both can have scientific > notation in their range outputs. > > Giuseppe, at least on my system r.mapcalc for floating point > expressions (if one of operands is floating point) defaults to double > (stored as DCELL). Still to be safe you can convert one of operands > (e.g. input map with ints) to double with double() as Markus already > pointed out. > > Good luck, > Māris. > -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Markus, output of r.univar and r.info both can have scientific notation in their range outputs. Giuseppe, at least on my system r.mapcalc for floating point expressions (if one of operands is floating point) defaults to double (stored as DCELL). Still to be safe you can convert one of operands (e.g. input map with ints) to double with double() as Markus already pointed out. Good luck, Māris. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
On Thu, Feb 25, 2021 at 2:32 PM Giuseppe Amatulli wrote: > > Thanks Maris!! > How can I force the output to be DCELL? Please try double() instead of float() in your formula. > How can I get the "Range of data:" without the scientific number notation? To which command do you refer to? Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Thanks Maris!! How can I force the output to be DCELL? How can I get the "Range of data:" without the scientific number notation? thanks Giuseppe On Thu, 25 Feb 2021 at 01:11, Maris Nartiss wrote: > Hello Giuseppe, > I am too lazy to calculate binary representation of your numbers, but > your suspicion of insufficient precision of float seems to be spot-on. > > If output is set to DCELL, then the result is exactly as you would > expect. Try yourself: > r.mapcalc expression="output=basin - 241981407231.0" > Range of data:min = 1 max = 3024784769025 > > Māris. > -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r. mapcalc
Hello Giuseppe, I am too lazy to calculate binary representation of your numbers, but your suspicion of insufficient precision of float seems to be spot-on. If output is set to DCELL, then the result is exactly as you would expect. Try yourself: r.mapcalc expression="output=basin - 241981407231.0" Range of data:min = 1 max = 3024784769025 Māris. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problem with r. mapcalc
Dear all I have some strange behaviour in r.mapcalc that i can not figure out the reason. I have a Float32 raster with very large pixels values wget https://www.dropbox.com/s/pxh473rs34wvxuc/basin_lbasin_172_oft_crop.tif?dl=0 min max 2419814072323266766176256 I want rescale to in such a way that the min is reachin 1 and the maximum value is - min Therfore min=241981407231.0 r.mapcalc " output = float( float(input) - $min ) " and i get min max output 1 3024784719872 which rather should be 3266766176256 - 241981407231 = 3024784769025 It seems to me that the subtraction is working fine for small numbers but not for larger numbers. I tried all the combinations of r.mapcalc " output = float( float(input) - $min ) " r.mapcalc " output = float( input - $min ) " Attached the script. Did I reach some numerical limitation? Any suggestions? Thanks giuseppe -- Giuseppe Amatulli, Ph.D. Research scientist at School of the Environment Yale University New Haven, CT, USA - 06511 Tweeter: @BigDataEcology Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ sc39_lbasin_basin_uniq_CompUnit_test.sh Description: application/shellscript ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user