<div dir="ltr"><div>Hi Ari and all,</div><div><br></div>why not use <a href="https://en.wikipedia.org/wiki/Machine_epsilon">machine epsilon</a>? somewhat over 1e-16 for double precision, or an even more tolerant tolerance? Most cases of meter coordinates 0.001 is realistic.<div>Given projection errors, a bit more is also defensible.<br><div><br></div><div>Am I to simplistic?</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 11, 2017 at 11:05 AM, Ari Jolma <span dir="ltr"><<a href="mailto:ari.jolma@gmail.com" target="_blank">ari.jolma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been bitten twice, once with ArcGIS and now with Rasdaman WCS, with numeric accuracy.<br>
<br>
I'm making a data request on the corner of the bounding box, let's say it has minimum X of 75042.7273594. I'm setting my minX to that value and I'm enforcing it to that value with MAX (this was introduced because of a case with ArcGIS). The I print that to the request with "%.18g" (it was "%.15g" earlier but I changes it to that because of ArcGIS) and the result is 75042.7273593999998, which is not good for Rasdaman, since it is formally less than 75042.7273594. Although, in gdb<br>
<br>
(gdb) p 75042.7273594 > 75042.727359399999<br>
$7 = false<br>
<br>
Any ideas how to detect/prevent these kinds of situations? Keep the checks and go back to "%.15g"? Not ok with ArcGIS.<br>
<br>
Ari<br>
<br>
<br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a></blockquote></div><br></div>