binary coding of negative values

David Houlder david at
Fri Jun 9 08:00:00 EDT 1995

> I'm writing a program to input uncompressed
> cell files to Splus. I have no problems to
> import files coded with 1,2 or 4 bytes per
> pixel provided the map is all positive,
> but I get weird numbers importing negative
> values (regardless of # of bytes). I'm sure
> my program works as it is supossed to because
> I have double checked importing grass cell maps
> with negative values to other programs (i.e.,
> Spyglass for Mac) and get the same weird 
> results. Are negative values coded in 
> some particular way in grass? Why?
> I've found that a file created as:
> r.mapcalc " = -1"
> r.compress -u
> is coded in 4 bytes per pixel. Why?
> Thanks
> Agus

Firstly, doing anything with grass' internal representation of data is
probably a bad idea. Who knows what its going to look like in the next
release. Get the grass programmer's manual and have a look at the
section regarding reading and writing rasters. There are a bunch of
function calls that provide an applications program interface to the
underlying data structure, whatever that may be.  I suspect that if you
use the API you will probably get sensible negative numbers.

As for the weird negatives, how about this for a theory: Some machines
use "sign extension" when promoting shorter ints to longer ints (i.e.
sign bit gets replicated all the way to the MSB of the word), and some
just fill out the rest with zeroes and set the MSB accordingly. I
suspect both these models are at work in your case, the conflict giving
you weird negatives but sane positives.

David Houlder                           Phone:  +61 6 249 4613
Geography Department                (In Aust.:  (06) 249 4613)
The Australian National University        Fax:  +61 6 249 3770

More information about the grass-dev mailing list