Re: Floating point comparison inconsistencies of the geometric types

On 06/01/2016 07:52 AM, Jim Nasby wrote:
> On 6/1/16 9:27 AM, Tom Lane wrote:
>> Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
>>> > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
>>> wrote:
>>>> >> Figuring out what to do about it is harder. Your proposal seems
>>>> to be
>>>> >> to remove them except where we need the fuzzy behavior, which
>>>> doesn't
>>>> >> sound unreasonable, but I don't personally understand why we need it
>>>> >> in some places and not others.
>>> > +1
>>> > My first inclination is to remove those macros in version 10, but
>>> > it would be good to hear from some people using these types on what
>>> > the impact of that would be.
>> As I understand it, the key problem is that tests like "is point on line"
>> would basically never succeed except in the most trivial cases,
>> because of
>> roundoff error. That's not very nice, and it might cascade to larger
>> problems like object-containment tests failing unexpectedly. We would
>> need to go through all the geometric operations and figure out where that
>> kind of gotcha is significant and what we can do about it. Seems like a
>> fair amount of work :-(. If somebody's willing to do that kind of
>> investigation, then sure, but I don't think just blindly removing these
>> macros is going to lead to anything good.
>
> I suspect another wrinkle here is that in the GIS world a single point
> can be represented it multiple reference/coordinate systems, and it
> would have different values in each of them. AIUI the transforms between
> those systems can be rather complicated if different projection methods
> are involved. I don't know if PostGIS depends on what these macros are
> doing or not. If it doesn't, perhaps it would be sufficient to lop of
> the last few bits of the significand. ISTM that'd be much better than
> what the macros currently do.

IIRC PostGIS uses a function from libgeos to do things like "point
equals" (ST_Equals). I've never looked at that source, but would be
unsurprised to find that it does something similar to this although
probably also more sophisticated.

(looks) yes -- ST_Equals calls GEOSEquals() after some sanity checking...

> BTW, I suspect the macro values were chosen specifically for dealing
> with LAT/LONG.

I think that is it exactly.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development