<div dir="ltr">Once upon a time we had Travis running with -Ofast which is a very --ffast-math --march=native, and it passed all tests at the time. It took some to get out the tests like the one in question, testing functionally equivalent but minorly different options. For a nn% performance increase I'd take it, maybe we should put such config back.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 29, 2021 at 9:50 PM Raúl Marín <raul@rmr.ninja> 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">Hi,<br>
<br>
Regarding the tests: distance2d_sqr_pt_seg used to be "tested" by all <br>
the users of ptarray_dp_findsplit_in_place (like simplify) but that was <br>
removed as part of the same patch (with included many other commits).<br>
<br>
And regarding the test change itself, I also don't think it's worth <br>
trying to get a universal behaviour. Unless you can guarantee same <br>
rounding (which we really can't unless we set it every time we want to <br>
do an operation), precision (which would need to be enforced during <br>
compilation to make doubles exact 64-bit IEEE754 and disable 80-bit <br>
operations), compiler options (no fast math) and so on I would try to <br>
get something that tests the behaviour and just works.<br>
<br>
Regards,<br>
Raúl.<br>
<br>
On 2021-09-29 17:55, Paul Ramsey wrote:<br>
> Yes, I think you've articulated what I was feeling. Trying to get universally consistent behaviour on all platforms will be "chasing the rabbit", having less fuzzy unit test would be better. Both answers are correct, they are just different.<br>
><br>
> P<br>
><br>
>> On Sep 29, 2021, at 8:53 AM, Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<br>
>><br>
>> My vote is to change the test so that it executes correctly on all platforms. Probably by displacing the point upwards slightly so that the second segment is clearly closer.<br>
>><br>
>> Users of this function will have to accept that it has a small amount of "jitter" on different platforms, and not rely on that behaviour.<br>
>><br>
>> On Wed, Sep 29, 2021 at 8:14 AM Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>> wrote:<br>
>> Reguarding <a href="https://trac.osgeo.org/postgis/ticket/5004" rel="noreferrer" target="_blank">https://trac.osgeo.org/postgis/ticket/5004</a><br>
>><br>
>> We have an liblwgeom function returning the "closest segment"<br>
>> to a given point. One of our test uses a query point which<br>
>> is on the continuation of the first segment of an L-shaped<br>
>> geometry:<br>
>><br>
>> ^<br>
>> |<br>
>> |<br>
>> |<br>
>> |<br>
>> ---------' . Query point<br>
>><br>
>> The test is expecting the first segment to be returned (seg 0)<br>
>> as the distance from both segments should be equal, closest point<br>
>> being the lower-right vertex of that LineString.<br>
>><br>
>> But on a 32bit system, and under certain conditions, the second<br>
>> segment is returned, although the distance from it is the same<br>
>> up to the 20th significant digits, so there must be a very very<br>
>> subtle difference in distance calculation based on the<br>
>> segment-to-point distance function (distance2d_sqr_pt_seg)<br>
>><br>
>> Do you think we should make an effort to avoid divisions<br>
>> when points have the same Y or X (as in this case) to gain<br>
>> more numerical stability or should we just accept that<br>
>> the code gives unstable results there and thus change<br>
>> the unit test and ensure no promise is given on the matter ?<br>
>><br>
>> BTW, I see there are no unit tests for distance2d_sqr_pt_seg()<br>
>> function, which was last touched by Raúl in commit<br>
>> 86057e2e46a272838a54eff9e6ebb5e56f33fab7<br>
>><br>
>> --strk;<br>
>><br>
>> Libre GIS consultant/developer<br>
>> <a href="https://strk.kbt.io/services.html" rel="noreferrer" target="_blank">https://strk.kbt.io/services.html</a><br>
>> _______________________________________________<br>
>> postgis-devel mailing list<br>
>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
>> _______________________________________________<br>
>> postgis-devel mailing list<br>
>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
<br>
<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>