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

[Raúl Marín]

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