[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 cmbarton):

 Replying to [comment:12 glynn]:
 > Replying to [comment:7 cmbarton]:
 >
 > > Thanks again. We can follow this to ensure the matches within Java. I
 just wondered if this would be better accomplished within grass.region().
 This returns a dictionary (seen in our original post). I can't say exactly
 where the lossy conversion is happening--going into the dictionary, coming
 out of the dictionary, or at some other point.
 >
 > To be honest, I think that you're getting confused by Python's repr()
 (which is what's used to display the result when you enter an expression
 at the interactive prompt) using excess precision. Converting from decimal
 to floating-point results in an approximation, then repr() shows the
 approximated value exactly.
 >
 > >It's clear from your explanation that the representation of these
 values can change at various places. This all makes sense. But still most
 users would expect grass.run_command('g.region', flags='gp') and
 grass.region() to give the same results.
 >
 > They can't give the same results. One returns strings, the other
 numbers. These can never be the same thing:
 > {{{
 > > 4293588.60267 == '4293588.60267'
 > False
 > }}}
 > Even if you use you use run_command('g.region') to get the strings, as
 soon as you pass those strings to any GRASS module, they're going to be
 converted to floating-point.

 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. Within the GRASS environment, including
 Python, it doesn't really make any difference, since it is clear that
 str(extent) or print(extent) will produce the same result as g.region.

 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. 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.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1161#comment:13>
GRASS GIS <http://grass.osgeo.org>