Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Got it, but if other people don't agree then this is going nowhere. Yes. As I wrote, I don't particularly care about functions like "is point on line". I can prepare a patch to fix as many problems as possible around those operators by preserving the current epsilon. I though we were arguing

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Tue, Jan 31, 2017 at 1:06 PM, Emre Hasegeli 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,

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Backing up a bit here, have we lost track of the problem that we're > trying to solve? Tom gave his opinion here: > > https://www.postgresql.org/message-id/3895.1464791...@sss.pgh.pa.us > > But I don't see that the latest patch I can find does anything to fix > that. This is what he wrote: >

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Thu, Jan 26, 2017 at 5:53 AM, Emre Hasegeli wrote: > Though, I know the community is against behaviour changing GUCs. I > will not spend more time on this, before I get positive feedback from > others. As if on cue, let me say that a behavior-changing GUC sounds like a

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Thu, Jan 26, 2017 at 9:11 PM, Kyotaro HORIGUCHI wrote: >> Though, I know the community is against behaviour changing GUCs. I >> will not spend more time on this, before I get positive feedback from >> others. > > That's too bad. I'm sorry that I wasn't very

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Thu, 26 Jan 2017 11:53:28 +0100, Emre Hasegeli wrote in > > Even though I'm not sure but I don't see a "natural" (or > > agreeable by many poeple) ordering of geometric types in > > general. Anyway

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Even though I'm not sure but I don't see a "natural" (or > agreeable by many poeple) ordering of geometric types in > general. Anyway it's quite application (not application program > but the relationship with the real world) specific. We can just define it for point as "ORDER BY point.x,

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, Emre. At Wed, 25 Jan 2017 12:24:18 +0100, Emre Hasegeli wrote in > I am responding both of your emails together. > > > Perhaps I don't understand it. Many opclass are defined for > > btree. But since

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

I am responding both of your emails together. > Perhaps I don't understand it. Many opclass are defined for > btree. But since (ordinary) btree handles only one-dimentional, > totally-orderable sets, geometric types even point don't fit > it. Even if we relaxed it by removing EPSILON,

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Sorry, this is the continuation of the previous comment. At Wed, 18 Jan 2017 17:36:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170118.173612.13506164.horiguchi.kyot...@lab.ntt.co.jp> > Hello. > > (I apologize in advance for possible

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello. (I apologize in advance for possible inaccurate wording on maths, which might cause confusion..) At Wed, 11 Jan 2017 16:37:59 +0100, Emre Hasegeli wrote in > > - Floating point comparisons for

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> - Floating point comparisons for gemetric types > > Comparison related to geometric types is performed by FPeq > macro and similars defined in geo_decls.h. This intends to give > tolerance to the comparisons. > > A > FPeq: |<=e-|-e=>|(<= means inclusive, e =

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Fri, 18 Nov 2016 10:58:27 +0100, Emre Hasegeli wrote in > > To keep such kind of integrity, we should deeply consider about > > errors. > > My point is that I don't think we can keep integrity

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, # Sorry for a trash I emitted before.. Perhaps you don't assume any calculations applied on stored geo-type values. Please be patient to disucuss with me. (Sorry for perhas hard-to-read English..) At Fri, 18 Nov 2016 10:58:27 +0100, Emre Hasegeli wrote in

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> 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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Mon, 14 Nov 2016 11:41:52 +0100, Emre Hasegeli wrote in > > What way to deal with it is in your mind? The problem hides > > behind operators. To fix it a user should rewrite a expression > > using

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> What way to deal with it is in your mind? The problem hides > behind operators. To fix it a user should rewrite a expression > using more primitive operators. For example, (line_a # point_a) > should be rewritten as ((point_a <-> lineseg_a) < EPSILON), or in > more primitive way. I regared this

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Sun, 13 Nov 2016 22:41:01 +0100, Emre Hasegeli wrote in > > We can remove the fuzz factor altogether but I think we also > > should provide a means usable to do similar things. At least "is > > a

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> We can remove the fuzz factor altogether but I think we also > should provide a means usable to do similar things. At least "is > a point on a line" might be useless for most cases without any > fuzzing feature. (Nevertheless, it is a problem only when it is > being used to do that:) If we don't

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> The reason for that is that you forgot to edit an alternative > exptect file, which matches for en_US locale. Now I understand. Thank you for the explanation. > But the test doesn't for collation and the only difference > between the alternative expect files comes from the difference of >

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, > Aside from that, I'd like to comment this patch on other points > later. The start of this patch is that the fact that most of but not all geometric operators use fuzzy comparson. But Tom pointed out that the fixed fuzz factor is not reasonable but hard to find how to modify it. We can

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, > > Returning to the issue, the following query should give you the > > expected result. > > > > SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2; > > Yes, I have worked around it like this. What I couldn't understand is > how my patch can cause this regression. How is it

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Returning to the issue, the following query should give you the > expected result. > > SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2; Yes, I have worked around it like this. What I couldn't understand is how my patch can cause this regression. How is it passes on master

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Thu, 29 Sep 2016 10:37:30 +0200, Emre Hasegeli wrote in > > regression=# select 'I- 580Ramp' < 'I- 580/I-680 > > Ramp'; > > ?column? > > -- > >

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Well, those two results are not contradictory -- notice that you > switched the order of the values in the comparison. I don't think > you've really found the explanation yet. I am sorry I copy-pasted the wrong example: "select_views" test runs: > SELECT name, #thepath FROM iexit ORDER BY 1,

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Sep 28, 2016 at 2:04 PM, Kevin Grittner wrote: > Will take a look and post again. I am moving this patch to the next CF. You'll be hearing from me sometime after this CF is closed. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Sep 28, 2016 at 12:02 PM, Emre Hasegeli wrote: >> `make check` finds differences per the attached. Please >> investigate why the regression tests are failing and what the >> appropriate response is. > > I fixed the first one and workaround the second with COLLATE "C".

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Emre, are you going to address the above? It would have to be Real > Soon Now. Yes, I am working on it. I found more problems, replaced more algorithms. That took a lot of time. I will post the new version really soon. I wouldn't feel bad, if you wouldn't have enough time to review it in

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Fri, Sep 9, 2016 at 4:25 PM, Kevin Grittner wrote: > On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote: > These patches apply and build on top of 5c609a74 with no problems, > but `make check` finds differences per the attached. Please > investigate

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote: >> The first patch fails to apply due to bit-rot. That's easy enough >> to correct, but then it runs into warnings on make: > > Rebased and fixed. These patches apply and build on top of 5c609a74 with no problems, but

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Mon, Jul 18, 2016 at 3:54 PM, Emre Hasegeli wrote: > My progress so far is attached as 2 patches. First one introduces an > header file for adt/float.c. Second one refactors the geometric > operations. The first patch fails to apply due to bit-rot. That's easy enough to

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 10:27 AM, Tom Lane 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 >

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Paul Ramsey writes: > One of the things people find annoying about postgis is that > ST_Intersects(ST_Intersection(a, b), a) can come out as false (a > derived point at a crossing of lines may not exactly intersect either > of the input lines), which is a direct result

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby wrote: > 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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On 06/01/2016 07:52 AM, Jim Nasby wrote: > On 6/1/16 9:27 AM, Tom Lane wrote: >> Kevin Grittner writes: >>> > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas >>> wrote: >> Figuring out what to do about it is harder. Your proposal seems to be

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 7:52 AM, Jim Nasby wrote: > > 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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On 6/1/16 9:27 AM, Tom Lane wrote: Kevin Grittner writes: > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas 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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Kevin Grittner writes: > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas 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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote: > On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote: >> There are those macros defined for the built-in geometric types: >> >>> #define EPSILON 1.0E-06 >> >>> #define FPzero(A)

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote: > There are those macros defined for the built-in geometric types: > >> #define EPSILON 1.0E-06 > >> #define FPzero(A) (fabs(A) <= EPSILON) >> #define FPeq(A,B) (fabs((A) - (B)) <=

[HACKERS] Floating point comparison inconsistencies of the geometric types

There are those macros defined for the built-in geometric types: > #define EPSILON 1.0E-06 > #define FPzero(A) (fabs(A) <= EPSILON) > #define FPeq(A,B) (fabs((A) - (B)) <= EPSILON) > #define FPne(A,B) (fabs((A) - (B)) > EPSILON) > #define