Okay, this all is starting to make sense. I was not aware of the &quot;funnyness&quot; in Python when it comes to decimals. Although it would be quite possible for the scripter to turn everything into strings before doing comparisons, I wonder if the best solution is to add a &quot;string&quot; option to those python grass libs that return output as dictionaries/lists. If one does not invoke this new option, dictionary/list items are &quot;numbers&quot; in whatever precision they come out as, but if one does invoke it, dictionary/list items are strings. In any case, this behavior should be added as a note in the grass python scripts description pages.<br>
<br>Cheers,<br><br>Isaac Ullah<br><br><div class="gmail_quote">On Sun, Oct 3, 2010 at 6:18 PM, GRASS GIS <span dir="ltr">&lt;<a href="mailto:trac@osgeo.org">trac@osgeo.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
#1161: g.region and <a href="http://r.info" target="_blank">r.info</a> decimal issue when using grass python libs<br>
-------------------------+--------------------------------------------------<br>
  Reporter:  isaacullah  |       Owner:  grass-dev@…<br>
      Type:  defect      |      Status:  closed<br>
  Priority:  normal      |   Milestone:  6.4.1<br>
 Component:  Python      |     Version:  6.4.0<br>
Resolution:  invalid     |    Keywords:  g.region, precision<br>
  Platform:  All         |         Cpu:  All<br>
-------------------------+--------------------------------------------------<br>
Changes (by hamish):<br>
<br>
  * keywords:  =&gt; g.region, precision<br>
<br>
<br>
Comment:<br>
<br>
 Replying to [comment:8 hamish]:<br>
 &gt; I guess what I find weird is that g.region will never report<br>
 &gt; with precision &gt; .15g, which is exactly representable<br>
<br>
 well, no, as in the &quot;5.1&quot; example. but reproducible anyhow..<br>
<br>
 &gt; &amp; will never saturate the double-prec bitspace, and so the python<br>
 &gt; repr() example above is perhaps using %.16f internally?<br>
<br>
 anyway, if it matters python&#39;s &quot;print&quot; gives it back to you in the form<br>
 you were expecting,<br>
<br>
 {{{<br>
 &gt;&gt;&gt; n = 4293588.60267<br>
 &gt;&gt;&gt; n<br>
 4293588.6026699999<br>
 &gt;&gt;&gt; print n<br>
 4293588.60267<br>
 }}}<br>
<br>
<br>
 Hamish<br>
<br>
 ps- do you mind if I move LandDyn/ in addons svn to raster/LandDyn?<br>
<font color="#888888"><br>
--<br>
Ticket URL: &lt;<a href="https://trac.osgeo.org/grass/ticket/1161#comment:10" target="_blank">https://trac.osgeo.org/grass/ticket/1161#comment:10</a>&gt;<br>
GRASS GIS &lt;<a href="http://grass.osgeo.org" target="_blank">http://grass.osgeo.org</a>&gt;<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Isaac I Ullah, M.A.<br><br>Archaeology PhD Candidate,<br>ASU School of Evolution and Social Change<br><br>Research Assistant,<br>Mediterranean Landscape Dynamics Project<br>
***************************************************<br><a href="mailto:isaac.ullah@asu.edu">isaac.ullah@asu.edu</a><br><a href="mailto:ullah@archaeologist.com">ullah@archaeologist.com</a><br><br><a href="http://www.public.asu.edu/~iullah">http://www.public.asu.edu/~iullah</a><br>
***************************************************<br>