[GRASS-dev] Re: [GRASS GIS] #1161: g.region and r.info decimal issue when using grass python libs

[GRASS GIS]

#1161: g.region and r.info decimal 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:  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>