<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">Yeah, I have that problem also when testing on different platforms/compilers/postgres<br>But I resolved by using on some tests that were having precision problems with:<br><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">SET extra_float_digits = </span><span style="font-weight:bold;color:rgb(255,84,84);background-color:rgb(255,255,255)">-3</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">;</span></span><br><a href="https://github.com/pgRouting/pgrouting/blob/main/pgtap/withPoints/withPoints_oneToOne-compare-dijkstra.test.sql#L30">https://github.com/pgRouting/pgrouting/blob/main/pgtap/withPoints/withPoints_oneToOne-compare-dijkstra.test.sql#L30</a><br>Documentation about that can be found here:<br><a href="https://www.postgresql.org/docs/12/datatype-numeric.html">https://www.postgresql.org/docs/12/datatype-numeric.html</a><br></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace">In another case I had to resolve floating point comparison internally with:<br><a href="https://github.com/pgRouting/pgrouting/blob/main/src/common/xy_vertex.cpp#L36">https://github.com/pgRouting/pgrouting/blob/main/src/common/xy_vertex.cpp#L36</a></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"></span></div><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">Which I got from here:<br><a href="https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon">https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon</a></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace">Allways keep in mind floating point <br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace">Remember for example that:</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace">mathematically: <span style="font-family:monospace">1 == 1/3 + 1/3 + 1/3</span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace">But computationally: <span style="font-family:monospace"><span style="font-family:monospace">1 != 1/3 + 1/3 + 1/3<br></span></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><span style="font-family:monospace"><span style="font-family:monospace">The reason is floating point<br></span></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><span style="font-family:monospace"><span style="font-family:monospace"><br></span></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><span style="font-family:monospace"><span style="font-family:monospace">I like this article<br></span></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><span style="font-family:monospace"><span style="font-family:monospace"><a href="https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/">https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/</a></span></span></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace"><br>
</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 22, 2021 at 7:56 AM Esteban Zimanyi <<a href="mailto:estebanzimanyi@gmail.com">estebanzimanyi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Vicky and Regina<div><br></div><div>Following the recommendations we received at the PostGIS Dev meeting this August 20, I started to experiment the embedding of liblwgeom from PostGIS 3.1.3 inside MobilityDB. I was able to run the MobilityDB tests but obviously things have changed from versions 2.5.5 to 3.1.3. </div><div><br></div><div>You will find enclosed a diff of the results of one of the tests. As you can see there are two types of differences. The first one concerns a very small floating point precision difference, e.g.,</div><div><br></div><div> SELECT ST_AsText(trajectory(tnpoint 'Npoint(1, 0.5)@2000-01-01'));<br>- st_astext <br>---------------------------------------------<br>- POINT(48.71866291282778 77.76407051015086)<br>+ st_astext <br>+------------------------------------------<br>+ POINT(48.7186629128278 77.7640705101509)<br> (1 row)<br></div><div><br></div><div>Another type of error concerns deprecated functions</div><div><br></div><div> SELECT setPrecision(atGeometry(tnpoint '{Npoint(1, 0.3)@2000-01-01, Npoint(1, 0.5)@2000-01-02, Npoint(1, 0.5)@2000-01-03}', geometry 'SRID=5676;Polygon((50 50,50 100,100 100,100 50,50 50))'), 6);<br>-ERROR<br>-DETAIL: Library function 'intersects' was deprecated in PostGIS 3.0.0<br>-HINT: Consider running: SELECT postgis_extensions_upgrade()<br>+ setprecision <br>+----------------------------------------<br>+ {NPoint(1,0.3)@2000-01-01 00:00:00+00}<br>+(1 row)<br>+<br></div><div><br></div><div>In the forthcoming days I will be modifying the develop branch so that the tests can be run in both versions PostGIS 2.5.5 and 3.1.3.</div><div><br></div><div>Furthermore, as a consequence of the problem I reported on the ticket</div><div><a href="https://trac.osgeo.org/postgis/ticket/4979#comment:5" target="_blank">https://trac.osgeo.org/postgis/ticket/4979#comment:5</a><br></div><div>it is not possible to mix PostGIS 2.5.5 and 3.1.3 (e.g., use liblwgeom.so from PostGIS 2.5.5 with PostGIS 3.1.3 which was one of the tests planned) since all the lwgeom struct definitions have been changed.</div><div><br></div><div>Regards</div><div><br></div><div>Esteban</div><div><br></div><div>------------------------------------------------------------<br></div><div><div><div dir="ltr"><div dir="ltr"><div>Prof. Esteban Zimanyi<br>Department of Computer & Decision Engineering (CoDE) CP 165/15 <br>Universite Libre de Bruxelles <br>Avenue F. D. Roosevelt 50 <br>B-1050 Brussels, Belgium <br>fax: + 32.2.650.47.13<br>tel: + 32.2.650.31.85<br>e-mail: <a href="mailto:esteban.zimanyi@ulb.be" target="_blank">esteban.zimanyi@ulb.be</a><br>Internet: <a href="http://cs.ulb.ac.be/members/esteban/" target="_blank">http://cs.ulb.ac.be/members/esteban/</a><br>------------------------------------------------------------</div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>