Re: Floating point comparison inconsistencies of the geometric types

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Floating point comparison inconsistencies of the geometric types
Дата
Msg-id e7b225d7-565c-4716-340d-a6e98f857ff7@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Floating point comparison inconsistencies of the geometric types  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Floating point comparison inconsistencies of the geometric types  (Paul Ramsey <pramsey@cleverelephant.ca>)
Re: Floating point comparison inconsistencies of the geometric types  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
On 6/1/16 9:27 AM, Tom Lane wrote:
> Kevin Grittner <kgrittn@gmail.com> writes:
>> > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel safety tagging of extension functions
Следующее
От: Tom Lane
Дата:
Сообщение: Removing overhead commands in parallel dump/restore