Re: Floating point comparison inconsistencies of the geometric types - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Floating point comparison inconsistencies of the geometric types
Date
Msg-id aea67ff8-c088-4e5a-1106-41e1508eee6a@BlueTreble.com
Whole thread Raw
In response to Re: Floating point comparison inconsistencies of the geometric types  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Floating point comparison inconsistencies of the geometric types  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-hackers
On 6/1/16 10:03 AM, Paul Ramsey wrote:
> We don't depend on these, we have our own :/
> The real answer for a GIS system is to have an explicit tolerance
> parameter for calculations like distance/touching/containment, but
> unfortunately we didn't do that so now we have our own
> compatibility/boil the ocean problem if we ever wanted/were funded to
> add one.

Well it sounds like what's currently happening in Postgres is probably 
going to change, so how might we structure that to help PostGIS? Would 
simply lopping off the last few bits of the significand/mantissa work, 
or is that not enough when different GRSes are involved?
-- 
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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: JSON[B] arrays are second-class citizens
Next
From: "David G. Johnston"
Date:
Subject: Re: JSON[B] arrays are second-class citizens