[postgis-devel] closest_segment_2d corner case (32bit failure)

Wed Sep 29 13:18:35 PDT 2021

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.

On Wed, Sep 29, 2021 at 9:50 PM Raúl Marín <raul at rmr.ninja> wrote:

> Hi,
>
> Regarding the tests: distance2d_sqr_pt_seg used to be "tested" by all
> the users of ptarray_dp_findsplit_in_place (like simplify) but that was
> removed as part of the same patch (with included many other commits).
>
> And regarding the test change itself, I also don't think it's worth
> trying to get a universal behaviour. Unless you can guarantee same
> rounding (which we really can't unless we set it every time we want to
> do an operation), precision (which would need to be enforced during
> compilation to make doubles exact 64-bit IEEE754 and disable 80-bit
> operations), compiler options (no fast math) and so on I would try to
> get something that tests the behaviour and just works.
>
> Regards,
> Raúl.
>
> On 2021-09-29 17:55, Paul Ramsey wrote:
> > 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.
> >
> > P
> >
> >> On Sep 29, 2021, at 8:53 AM, Martin Davis <mtnclimb at gmail.com> wrote:
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> On Wed, Sep 29, 2021 at 8:14 AM Sandro Santilli <strk at kbt.io> wrote:
> >> Reguarding https://trac.osgeo.org/postgis/ticket/5004
> >>
> >> We have an liblwgeom function returning the "closest segment"
> >> to a given point. One of our test uses a query point which
> >> is on the continuation of the first segment of an L-shaped
> >> geometry:
> >>
> >>              ^
> >>              |
> >>              |
> >>              |
> >>              |
> >>     ---------'  . Query point
> >>
> >> The test is expecting the first segment to be returned (seg 0)
> >> as the distance from both segments should be equal, closest point
> >> being the lower-right vertex of that LineString.
> >>
> >> But on a 32bit system, and under certain conditions, the second
> >> segment is returned, although the distance from it is the same
> >> up to the 20th significant digits, so there must be a very very
> >> subtle difference in distance calculation based on the
> >> segment-to-point distance function (distance2d_sqr_pt_seg)
> >>
> >> Do you think we should make an effort to avoid divisions
> >> when points have the same Y or X (as in this case) to gain
> >> more numerical stability or should we just accept that
> >> the code gives unstable results there and thus change
> >> the unit test and ensure no promise is given on the matter ?
> >>
> >> BTW, I see there are no unit tests for distance2d_sqr_pt_seg()
> >> function, which was last touched by Raúl in commit
> >> 86057e2e46a272838a54eff9e6ebb5e56f33fab7
> >>
> >> --strk;
> >>
> >>    Libre GIS consultant/developer
> >>    https://strk.kbt.io/services.html
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210929/71db030b/attachment.html>