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

GRASS GIS trac at osgeo.org
Sun Oct 3 22:28:53 EDT 2010


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

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



More information about the grass-dev mailing list