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 wond
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 1
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, Niko
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/mail
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, Marku
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 preci
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
> Fl
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?
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.
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
_
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 s
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
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
13 matches
Mail list logo
