On Tue, Jan 31, 2017 at 1:06 PM, Emre Hasegeli <e...@hasegeli.com> wrote: > This is what he wrote: > >> 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 re-implemented "is point on line" operator on my patch so that it > would, at least, work on the most trivial cases.
Right. So you and he do not agree on the goal. He wants it to work in MORE than the most trivial cases, and you wrote it so that it will work in AT LEAST the most trivial cases. Those are not the same. > I listed the problems I am trying to solve in here: > > https://www.postgresql.org/message-id/CAE2gYzzNufOZqh4HO3Od8urzamNSeX-OXJxfNkRcU3ex9RD8jw%40mail.gmail.com Those problems boil down to "let's get rid of the tolerance completely", and there's no consensus on that being a good thing to do. In particular, I can't remember anybody but you being unequivocally in favor of it. > We couldn't agree on how we should treat on floating point numbers. I > think we should threat them just like the "float" datatype. Got it, but if other people don't agree then this is going nowhere. Personally, I've got my doubts about how sane it is to make anything work here with the built-in floating point types. The CPU is going to do some kind of black magic, which may differ between machines, and good luck getting consistent semantics that work everywhere. For example it seems entirely plausible (with some implementation) that you might find that (1, 2) is on the line from (0, 0) to (2, 4) but that (1, 3) is not on the line from (0, 0) to (2, 6) because the slope 1/2 can be represented exactly in base 2 and the slope 1/3 cannot. If you try to fix that kind of thing by introducing a tolerance, then you might get it wrong when the line goes from (0, 0) to (1000000000, 2000000001). Now, if we represented values using home-grown arbitrary-precision arithmetic - like numeric does - then it might be possible to get such cases right, especially if you supported exact rather than approximate representations of fractional quantities. Otherwise, I think there are inevitably going to be artifacts, and tinkering with this is just changing which artifacts we get without really solving the problem. But I am notorious for my low opinion of floating-point arithmetic; maybe somebody who understands it better or likes it more can come up with something that's more clearly an improvement. Regardless, we have to have an agreement in order to commit anything here, and I don't see one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers