#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 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>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
