Re: Floating point comparison inconsistencies of the geometric types

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.

BTW, I suspect the macro values were chosen specifically for dealing
with LAT/LONG.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461