[GRASS-user] Set default cell type to FCELL?

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/12 04:49, Glynn Clements wrote:
> 
> Rainer M Krug wrote:
> 
>> What I would like to do is tho change the default type from CELL 
>> to FCELL - i.e. whenever a new raster is created, it will 
>> *always* and *automatically* be saved in a FCELL raster, even if 
>> it only contains integer values, and not in a CELL raster.
> 
> This isn't possible.

Pitty - but makes sense.

> If a module generates a CELL map, it's invariably because it's 
> performing the calculations using integers. Converting the final 
> result to floating-point wouldn't help; if the integer
> calculations overflow, converting the result to floating-point
> won't "undo" the overflow.

Good point - so I have to change my approach.

> 
> Some modules will generate either integer or floating-point output
>  depending upon the type of the inputs.

Yes - I am referring mainly to r.mapcalc with the overflow - so I can
do the conversion in the formula.

> 
>> so
>> 
>> oldmap * 1
>> 
>> results in a raster of the same type as oldmap,
> 
> Arithmetic operations on mixed types promote to the lesser type to 
> the greater type, where CELL < FCELL < DCELL.

I assume the "to the lesser type" should be deleted? So they promote
to the higher type?

> 
>> where
>> 
>> oldmap * 1.0
>> 
>> would result in a FCELL?
> 
> Actually, it will result in DCELL. r.mapcalc follows C syntax: 
> floating-point literals are double precision unless suffixed with 
> an "f", so "oldmap * 1.0f" will result in FCELL (unless oldmap is 
> DCELL).

OK.

> 
> But float(oldmap) or double(oldmap) do the same thing but avoid the
> gratuitous multiply operation.

Agreed - and I am using them - the * 1 was just a (not very good) example.

> 
> Also:
> 
> 1. If you are having issues with overflow, you need to promote 
> values before calculations, e.g. "float(x) * y". Using "float(x * 
> y)" will result in x*y overflowing, then the overflowed value will 
> be converted.

Very good point - have to go through my code again.

> 
> 2. Single precision (FCELL) only has a 24-bit mantissa, so integers
> greater than 2^24 (16777216) cannot always be represented exactly.
> Double precision (DCELL) has a 53-bit mantissa.

So I will go to DCELL and double().

Thanks,

things are much clearer now.

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 at krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8NTD4ACgkQoYgNqgF2egpwQACfakWPvtlsaKBMBSbn10uNMLAR
PssAn0xf5gE+TSOujix1N2qs0Qw1aqoT
=4tuq
-----END PGP SIGNATURE-----