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

[Darafei "Komяpa" Praliaskouski]

Hi,

Can you build it with -fexcess-precision=standard? If it helps, we need to
add it to the 32-bit configure.

On Wed, Sep 29, 2021 at 6:14 PM 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/8a82f4e7/attachment.html>