[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