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

From Emre Hasegeli
Subject Re: Floating point comparison inconsistencies of the geometric types
Date
Msg-id CAE2gYzxVxKNS7qU74UdHVZTmfXQjxMbFiXH5+16XFy90SRAbXA@mail.gmail.com
Whole thread Raw
In response to Re: Floating point comparison inconsistencies of the geometric types  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Floating point comparison inconsistencies of the geometric types
Re: [HACKERS] Floating point comparison inconsistencies of thegeometric types
List pgsql-hackers
> To keep such kind of integrity, we should deeply consider about
> errors.

My point is that I don't think we can keep integrity together with the
fuzzy behaviour, or at least I don't have the skills to do that.  I
can just leave the more complicated operators like "is a
point on a line" as it is, and only change the basic ones.  Do you
think a smaller patch like this would be acceptable?

> That's a fate of FP numbers. Btree is uasble for such data since
> it is constructed using inequality operators but hash is almost
> unsuitable without rounding and normalization because of the
> nature of floating point numbers. Range scan on bree will work
> find but on the other hand equality doesn't work even on btree
> index from the same reason to the below.

Btree is very useful with floats.  There is no problem with it.

> Again, FP numbers generally cannot match exactly each other. You
> have to avoid that.

Again, they do match very well.  Floating point numbers are no magic.
They are perfectly deterministic.



pgsql-hackers by date:

Previous
From: Emre Hasegeli
Date:
Subject: Re: Contains and is contained by operators of inet datatypes
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take