> 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.