[postgis-devel] closest_segment_2d corner case (32bit failure)
Martin Davis
mtnclimb at gmail.com
Wed Sep 29 08:53:12 PDT 2021
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210929/8edf29b4/attachment.html>
More information about the postgis-devel
mailing list