[GRASS-user] Integer division with r.mapcalc

Luí­s Moreira de Sousa luis.de.sousa at protonmail.ch
Thu Apr 11 02:14:55 PDT 2024


Thanks Ondrej, that makes sense.

I just found the details in the Wiki [0], perhaps those should be in the manual.

Regards. 

[0] https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics

--
Luís


Sent with Proton Mail secure email.

On Thursday, April 11th, 2024 at 9:49 AM, Ondřej Pešek <pesej.ondrek at gmail.com> wrote:

> Hi Luís,
> 
> čt 11. 4. 2024 v 8:26 odesílatel Luí­s Moreira de Sousa via grass-user
> grass-user at lists.osgeo.org napsal:
> 
> > I am working with a raster with very large integers. That are stored as 64 bit floats (imported from a GTiff). I wish to extract part of these values with an integer division. The first approach was:
> > 
> > r.mapcalc 'short_ints = int(long_ints)/1000000'
> > 
> > However, this results in something that is not an integer division. In fact I have no idea what the result is. Eventually, I succeeded with the following formulation:
> > 
> > r.mapcalc 'psu_ids = int(ssu_ids/1000000)'
> > 
> > I have been going through the manual back and forth and can't understand why these two expressions produce different results. Any insights?
> 
> 
> This is probably due to the 32-bit size of `int()`. If your values are
> higher than `2 ** 31 -1` (i.e. 214783467; `31` because half of the
> numbers go to the negatives; `-1` because there is also NULL), the
> counter starts to rotate. It means that `2 ** 31` will be NULL and `2 ** 31 + 1` will be `- (2 ** 31 - 1)`. You can encounter this behaviour
> also in other software, such as in `numpy`.
> 
> Indeed, there is no mention of that in the docs. I will update it
> today to include this information. It is true that it's easy to break
> your teeth on this.
> 
> Cheers,
> Ondra


More information about the grass-user mailing list