#1161: g.region and r.info decimel issue when using grass python libs
-------------------------+--------------------------------------------------
Reporter: isaacullah | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.1
Component: Python | Version: 6.4.0
Resolution: invalid | Keywords:
Platform: All | Cpu: All
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:3 cmbarton]:
> > These functions simply parse the (decimal) output from g.region and
r.info. Python has printf-like formatting operations if you wish to use
them.
>
> Actually this is not what seems to be happening.
Yes it is.
> g.region and r.info produce single precision values, as expected.
g.region and r.info produce '''decimal''' values using
G_format_{northing,easting}, which uses either %.15g or %.8f (except for
lat/lon, which uses DMS). Both of these are better than IEEE single-
precision which has between 6 and 7 decimal digits. %.15g uses 15 decimal
digits (trailing zeros after the decimal pointer are omitted, as is the
decimal point itself if it is not required); %.8f uses as many digits as
are required before the decimal point and a further 8 digits after it.
> But the python library functions do not seem to be getting values from
these--
The Python functions are wrappers around "g.region -g" and "r.info
-rgstmpud", which parse the output into a dictionary, with the strings
parsed using float(), int() or float_or_dms() as appropriate.
> or are doing something strange with the values after the fact
Yes; if by "strange" you mean converting them to (double precision) binary
floating point values (which is a lossy operation; 10^-n^ (for n >= 1)
isn't exactly representable in binary).
OTOH, that isn't all that strange, given that the values started out as
floating point before g.region/r.info converted them to decimal (which
itself may be lossy; %.15g isn't quite enough for double precision, which
has slightly better than 15 decimal digits of precision).
> --in order to come up with double precision values. The result is that
the values in the dictionary produced by grass.region() and
grass.raster_info() are *different* from the values that come from
g.region or r.info. Therein lies the problem.
The values which come from g.region or r.info are '''strings''', each
comprising a decimal representation of a number. Most of the things which
you might want to do with that information will expect numbers rather than
strings, so the Python functions convert them to numbers automatically.
We could use Python's "decimal" package, although that doesn't work with
everything, still doesn't necessarily give you the original value, and
serves no purpose other than to work around bugs in scripts which expect
to be able to perform floating-point comparisons using "==" or (worse
still) string comparison. But if someone is making that kind of mistake,
they will have far bigger problems.
If you really need the exact output from g.region/r.info, use
grass.parse_command() (which will parse key/value output into a dictionary
but will leave the values as strings). But don't expect other commands to
return identical strings for the same information; there is no one
"correct" format string for coordinates.
> A region set using g.region is different from a region set using
grass.region(). The difference is not much
In the example give, it's around 10 microns. I'm not convinced that there
is a single set of geospatial data in existence which genuinely has that
accuracy.
> but it is enough to cause problems if you are comparing regions in a
boolean way
Which is a bug, and not one which will be solved by any changes to the
Python library. Any program which parses the output from g.region or
r.info will have exactly the same issues.
> or trying to overlay maps created with a setting in g.region and maps
created with a setting from grass.region().
Even on the largest map, the differences are nowhere near half a cell,
which is what would be required to move the sample point into the next
cell.
> My only guess is that somehow grass.region() is populating its
dictionary via a swig/ctype call instead of just parsing g.region.
It's just parsing the output from "g.region -g" via Python's float()
operator:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/core.py#L525
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/core.py#L485
> If this guess is wrong, then something else is happening to the values
after they are generated by g.region and before they go into the python
dictionary.
The only "something else" is that g.region() parses the decimal string to
a float, and "print" converts it back to a decimal string. Both of these
operations are lossy. But then just about anything which you do with a
floating-point value is lossy, including parsing the values from the
WIND/cellhd file in the first place.
Parsing a decimal string to a floating-point value is inherently lossy.
Converting a floating-point value to a decimal isn't inherently lossy but
in practice you invariably use far fewer digits than are required for an
exact representation, as the exact representation requires roughly 3 times
as many digits as are necessary for a unique representation.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1161#comment:4>
GRASS GIS <http://grass.osgeo.org>