#1161: g.region and r.info decimal issue when using grass python libs
-------------------------+--------------------------------------------------
Reporter: isaacullah | Owner: grass-...@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.1
Component: Python | Version: 6.4.0
Resolution: invalid | Keywords: g.region, precision
Platform: All | Cpu: All
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:13 cmbarton]:
> What I was thinking about was whether it is worth it or not to have an
option to do a string conversion of these within the python library
function so that the resulting dictionary has values that match the
results (also string) of g.region.
Those functions are intended for the situation where you want to actually
'''use''' the values (e.g. perform arithmetic on them, which you can't do
with strings).
If you want strings, you may as well just use
grass.parse_command('g.region', ...) etc. parse_command() parses key-value
output into a dictionary, but doesn't parse the values further unless
specifically instructed via the val_type argument.
> The place where it could be helpful is in in a case like we have--where
a Python script [using grass.region()] is being called and parsed by Java
and g.region is being called and parsed by Java. Maybe the Java equivalent
of the Python str() will also give the same answer or maybe it won't.
Why would the Java code be converting them to strings? Assuming that you
pass it strings via the command line, I would expect it to just convert
them to float/double. Any exact comparison is fragile, and an exact
comparison using strings even more so (e.g. 1.2 and 1.20 should compare
equal as floats but the strings "1.2" and "1.20" won't compare equal).
> This goes for other languages. I simply don't know--though we will run
some tests to see. Perhaps this is a rare enough case, that it isn't worth
the trouble to provide this option.
It isn't worth the trouble in any case. Code which performs equality
comparisons on coordinates should itself be fixed, rather than expecting
other code to be modified in order to satisfy its (incorrect) assumptions.
You should never perform equality comparisons on floats unless you
'''know''' that the values are exactly representable. Even then, you need
to be careful about optimisations such as -funsafe-math-optimizations (and
broken compilers; Borland C always performs such optimisations, with no
means to disable them).
You really shouldn't rely upon '''anything''' preserving floating-point
values exactly, not just conversions to/from decimal. E.g. even without
changing the WIND file, the values g.region gives for nsres/ewres can
change depending upon the compiler and compilation switches used. Code
which works fine on one architecture can break on a different
architecture, e.g. due to the 80-bit internal precision of x86, default
rounding mode, etc.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1161#comment:14>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
