Re: [PATCH] Improve geometric types

On 2018-Sep-27, Tomas Vondra wrote: > I may be missing what you're saying, but point_mul_point is not just a > simple multiplication of coordinates, i.e. > > (x1,y1) * (x2,y2) != (x1*x2, y1*y2) > > It essentially does this: > > ((x1 * x2 - y1 * y2), (x1 * y2 + x2 * y1)) > > so I

Re: [PATCH] Improve geometric types

On 09/27/2018 07:05 PM, Tom Lane wrote: > Tomas Vondra writes: >> On 09/27/2018 12:48 AM, Tom Lane wrote: >>> Actually, it seems simpler than that: gaur produces plus zero already >>> from the multiplication: >>> regression=# select '-3'::float8 * '0'::float8; >>> ?column? >>> -- >>> 0

Re: [PATCH] Improve geometric types

On 09/27/2018 07:21 PM, Alvaro Herrera wrote: > If you look at the differing results carefully, there's this one: > > *** 3249,3255 > ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) | > [(0,-0),(-15,-36),(40,-73),(67,-42)] > --- 3249,3255 > ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12)

Re: [PATCH] Improve geometric types

If you look at the differing results carefully, there's this one: *** 3249,3255 ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) | [(0,-0),(-15,-36),(40,-73),(67,-42)] --- 3249,3255 ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) | [(0,0),(-15,-36),(40,-73),(67,-42)] (Third column

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > On 09/27/2018 12:48 AM, Tom Lane wrote: >> Actually, it seems simpler than that: gaur produces plus zero already >> from the multiplication: >> regression=# select '-3'::float8 * '0'::float8; >> ?column? >> -- >> 0 >> (1 row) > Hmmm, interesting. But I still don't

Re: [PATCH] Improve geometric types

On 09/27/2018 12:48 AM, Tom Lane wrote: Tomas Vondra writes: On 09/26/2018 06:45 PM, Tom Lane wrote: gaur's not happy, but rather surprisingly, it looks like we're mostly OK elsewhere. Do you need me to trace down exactly what's going wrong on gaur? Or you could just try doing

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > On 09/26/2018 06:45 PM, Tom Lane wrote: >> gaur's not happy, but rather surprisingly, it looks like we're >> mostly OK elsewhere. Do you need me to trace down exactly what's >> going wrong on gaur? > Or you could just try doing > select '(0,0)'::point *

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > Hmmm, interesting. It seems both failures happen in the chunk that > multiplies paths with points, i.e. essentially point_mul_point. So it > seems most platforms end up with > (0,0) * (-3,4) = (-0, 0) > while gaur apparently thinks it's (0,0). And indeed, that's what

Re: [PATCH] Improve geometric types

On 09/26/2018 06:45 PM, Tom Lane wrote: > Tomas Vondra writes: >> Pushed. Now let's wait for the buildfarm to complain ... > > gaur's not happy, but rather surprisingly, it looks like we're > mostly OK elsewhere. Do you need me to trace down exactly what's > going wrong on gaur? > Hmmm,

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > Pushed. Now let's wait for the buildfarm to complain ... gaur's not happy, but rather surprisingly, it looks like we're mostly OK elsewhere. Do you need me to trace down exactly what's going wrong on gaur? regards, tom lane

Re: [PATCH] Improve geometric types

On 09/23/2018 11:55 PM, Tomas Vondra wrote: > On 09/03/2018 04:08 AM, Tom Lane wrote: >> Tomas Vondra writes: >>> On 08/17/2018 11:23 PM, Tom Lane wrote: Yeah, we've definitely hit such problems before. The geometric logic seems particularly prone to it because it's doing more and

Re: [PATCH] Improve geometric types

On 09/03/2018 04:08 AM, Tom Lane wrote: > Tomas Vondra writes: >> On 08/17/2018 11:23 PM, Tom Lane wrote: >>> Yeah, we've definitely hit such problems before. The geometric logic >>> seems particularly prone to it because it's doing more and subtler >>> float arithmetic than the rest of the

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > On 08/17/2018 11:23 PM, Tom Lane wrote: >> Yeah, we've definitely hit such problems before. The geometric logic >> seems particularly prone to it because it's doing more and subtler >> float arithmetic than the rest of the system ... but it's not the sole >> source of

Re: [PATCH] Improve geometric types

On 08/17/2018 11:23 PM, Tom Lane wrote: > Tomas Vondra writes: >> Hmm, yeah. Based on past experience, the powerpc machines are likely to >> stumble on this. > >> FWIW my understanding is that these failures actually happen in new >> tests, it's not an issue introduced by this patch series. > >

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > Hmm, yeah. Based on past experience, the powerpc machines are likely to > stumble on this. > FWIW my understanding is that these failures actually happen in new > tests, it's not an issue introduced by this patch series. Yeah, we've definitely hit such problems before.

Re: [PATCH] Improve geometric types

On 08/17/2018 08:56 PM, Tom Lane wrote: > Emre Hasegeli writes: >>> BTW how did we end up with the regression differences? Presumably you've >>> tried that on your machine and it passed. So if we adjust the expected >>> file, won't it fail on some other machines? > >> I had another patch to

Re: [PATCH] Improve geometric types

Emre Hasegeli writes: >> BTW how did we end up with the regression differences? Presumably you've >> tried that on your machine and it passed. So if we adjust the expected >> file, won't it fail on some other machines? > I had another patch to check for -0 inside float{4,8}_{div,mul}(). I >

Re: [PATCH] Improve geometric types

On 08/17/2018 08:24 PM, Emre Hasegeli wrote: >> BTW how did we end up with the regression differences? Presumably you've >> tried that on your machine and it passed. So if we adjust the expected >> file, won't it fail on some other machines? > > I had another patch to check for -0 inside

Re: [PATCH] Improve geometric types

> BTW how did we end up with the regression differences? Presumably you've > tried that on your machine and it passed. So if we adjust the expected > file, won't it fail on some other machines? I had another patch to check for -0 inside float{4,8}_{div,mul}(). I dropped it on the last set of

Re: [PATCH] Improve geometric types

On 08/17/2018 06:40 PM, Emre Hasegeli wrote: >> the buildfarm seems to be mostly happy so far, so I've taken a quick >> look at the remaining two parts. The patches still apply, but I'm >> getting plenty of failures in regression tests, due to 0.0 being >> replaced by -0.0. > > I think we are

Re: [PATCH] Improve geometric types

> the buildfarm seems to be mostly happy so far, so I've taken a quick > look at the remaining two parts. The patches still apply, but I'm > getting plenty of failures in regression tests, due to 0.0 being > replaced by -0.0. I think we are better off fixing them locally at the moment like your

Re: [PATCH] Improve geometric types

Hi, the buildfarm seems to be mostly happy so far, so I've taken a quick look at the remaining two parts. The patches still apply, but I'm getting plenty of failures in regression tests, due to 0.0 being replaced by -0.0. This reminds me 74294c7301, except that these patches don't seem to remove

Re: [PATCH] Improve geometric types

On 08/09/2018 11:42 AM, Kyotaro HORIGUCHI wrote: > At Wed, 8 Aug 2018 14:39:54 +0200, Tomas Vondra > wrote in > <6ecb4f61-1fb1-08a1-31d6-e58e9c352...@2ndquadrant.com> >> >> >> On 08/03/2018 02:39 PM, Tomas Vondra wrote: >>> On 08/03/2018 06:40 AM, Kyotaro HORIGUCHI wrote: ... I'm

Re: [PATCH] Improve geometric types

At Wed, 8 Aug 2018 14:39:54 +0200, Tomas Vondra wrote in <6ecb4f61-1fb1-08a1-31d6-e58e9c352...@2ndquadrant.com> > > > On 08/03/2018 02:39 PM, Tomas Vondra wrote: > > On 08/03/2018 06:40 AM, Kyotaro HORIGUCHI wrote: > >> ... > >> > >> I'm not confident on replacing double to float8 partially in

Re: [PATCH] Improve geometric types

On 08/03/2018 02:39 PM, Tomas Vondra wrote: On 08/03/2018 06:40 AM, Kyotaro HORIGUCHI wrote: ... I'm not confident on replacing double to float8 partially in gist code. After the 0002 patch applied, I see most of problematic usage of double or bare arithmetic on dimentional values in

Re: [PATCH] Improve geometric types

On 08/03/2018 06:40 AM, Kyotaro HORIGUCHI wrote: ... I'm not confident on replacing double to float8 partially in gist code. After the 0002 patch applied, I see most of problematic usage of double or bare arithmetic on dimentional values in gistproc.c. static inline float non_negative(float

Re: [PATCH] Improve geometric types

At Fri, 03 Aug 2018 13:38:40 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180803.133840.180843182.horiguchi.kyot...@lab.ntt.co.jp> > At Thu, 2 Aug 2018 11:50:55 +0200, Tomas Vondra > wrote in > > > > > > > On 08/01/2018 01:40 PM, Emre Hasegeli wrote: > > >> Ah, so there's an

Re: [PATCH] Improve geometric types

At Thu, 2 Aug 2018 11:50:55 +0200, Tomas Vondra wrote in > > > On 08/01/2018 01:40 PM, Emre Hasegeli wrote: > >> Ah, so there's an assumption that NaNs are handled earlier and never > >> reach > >> this place? That's probably a safe assumption. I haven't thought about > >> that, > >> it

Re: [PATCH] Improve geometric types

On 08/01/2018 01:40 PM, Emre Hasegeli wrote: Ah, so there's an assumption that NaNs are handled earlier and never reach this place? That's probably a safe assumption. I haven't thought about that, it simply seemed suspicious that the code mixes direct comparisons and float8_mi() calls. The

Re: [PATCH] Improve geometric types

> Hmmm. It'll be difficult to review such patch without access to a platform > exhibiting such behavior ... IIRC IBM offers free access to open-source > devs, I wonder if that would be a way. I don't have access to such platform either, and I don't know too much about this business. I left this

Re: [PATCH] Improve geometric types

On 07/31/2018 05:14 PM, Emre Hasegeli wrote: 1) common_entry_cmp is still handling 'delta' as double, although the CommonEntry was modified to use float8. IMHO it should also simply call float8_cmp_internal instead of doing comparisons. I am changing it to define delta as "float8" and to

Re: [PATCH] Improve geometric types

> 1) common_entry_cmp is still handling 'delta' as double, although the > CommonEntry was modified to use float8. IMHO it should also simply call > float8_cmp_internal instead of doing comparisons. I am changing it to define delta as "float8" and to use float8_cmp_internal(). > 2)

Re: [PATCH] Improve geometric types

Hi Emre, Now that the buildfarm is no longer complaining about 0001 and 0002, I'm working on reviewing and committing 0003. It seems quite straightforward but I do have couple of comment/questions: 1) common_entry_cmp is still handling 'delta' as double, although the CommonEntry was

Re: [PATCH] Improve geometric types

> OK, thanks for confirming. I'll get it committed and we'll see what the > animals think soon. Thank you for fixing this. I wanted to preserve this code but wasn't sure about the correct place or whether it is still necessary. There are more places we produce -0. The regression tests have

Re: [PATCH] Improve geometric types

On 07/29/2018 10:57 PM, Tom Lane wrote: > Tomas Vondra writes: >> This should fix it I guess, and it's how we deal with unused return >> values elsewhere. I've considered using USE_ASSERT_CHECKING here, but it >> seems rather ugly with that. I'll wait for Emre's opinion ... > > I think what you

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > This should fix it I guess, and it's how we deal with unused return > values elsewhere. I've considered using USE_ASSERT_CHECKING here, but it > seems rather ugly with that. I'll wait for Emre's opinion ... I think what you want is to mark the variable with

Re: [PATCH] Improve geometric types

On 07/29/2018 08:02 PM, Tom Lane wrote: > I wrote: >> Tomas Vondra writes: >>> On 07/29/2018 05:14 PM, Tomas Vondra wrote: FWIW I think this should fix it. Can someone with access to an affected machine confirm? > >>> Gah, shouldn't have posted before trying to compile it. Here is a

Re: [PATCH] Improve geometric types

I wrote: > Tomas Vondra writes: >> On 07/29/2018 05:14 PM, Tomas Vondra wrote: >>> FWIW I think this should fix it. Can someone with access to an affected >>> machine confirm? >> Gah, shouldn't have posted before trying to compile it. Here is a fixed >> version of the fix. > Sure, I'll try this

Re: [PATCH] Improve geometric types

On 07/29/2018 05:14 PM, Tomas Vondra wrote: > On 07/29/2018 02:03 PM, Tomas Vondra wrote: >> >> ... >> >> Hmm, I see. I think adding it to the else branch should do the trick, >> then, I guess. But I'd be much happier if I could test it somewhere >> before the commit. >> > > FWIW I think this

Re: [PATCH] Improve geometric types

On 07/29/2018 02:03 PM, Tomas Vondra wrote: > > > On 07/29/2018 01:28 PM, Thomas Munro wrote: >> On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro >> wrote: >>> On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra >>> wrote: It's always 0/-0 difference, and it's limited to power machines. I'll

Re: [PATCH] Improve geometric types

On 07/29/2018 04:31 PM, Jeff Janes wrote: > > > On Sat, Jul 28, 2018 at 9:54 PM, Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > > > I've committed the first two parts, after a review and testing. > > > I'm getting a compiler warning now: > > geo_ops.c: In function

Re: [PATCH] Improve geometric types

On Sat, Jul 28, 2018 at 9:54 PM, Tomas Vondra wrote: > > > I've committed the first two parts, after a review and testing. > > I'm getting a compiler warning now: geo_ops.c: In function 'line_closept_point': geo_ops.c:2528:7: warning: variable 'retval' set but not used

Re: [PATCH] Improve geometric types

On 07/29/2018 01:28 PM, Thomas Munro wrote: > On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro > wrote: >> On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra >> wrote: >>> It's always 0/-0 difference, and it's limited to power machines. I'll >>> try to get access to such system and see what's

Re: [PATCH] Improve geometric types

On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro wrote: > On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra > wrote: >> It's always 0/-0 difference, and it's limited to power machines. I'll >> try to get access to such system and see what's wrong. > > This is suspicious: > > /* on some

Re: [PATCH] Improve geometric types

On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra wrote: > It's always 0/-0 difference, and it's limited to power machines. I'll > try to get access to such system and see what's wrong. This is suspicious: /* on some platforms, the preceding expression tends to produce -0 */ if

Re: [PATCH] Improve geometric types

On 07/29/2018 03:54 AM, Tomas Vondra wrote: > > > On 07/27/2018 10:20 AM, Kyotaro HORIGUCHI wrote: >> Thank you for taking this. >> >> At Thu, 26 Jul 2018 17:12:50 +0200, Tomas Vondra >> wrote in >> <672f4c42-6742-c1ec-e9a4-1994b815a...@2ndquadrant.com> >>> On 07/11/2018 07:13 PM, Emre

Re: [PATCH] Improve geometric types

On 07/27/2018 10:20 AM, Kyotaro HORIGUCHI wrote: > Thank you for taking this. > > At Thu, 26 Jul 2018 17:12:50 +0200, Tomas Vondra > wrote in > <672f4c42-6742-c1ec-e9a4-1994b815a...@2ndquadrant.com> >> On 07/11/2018 07:13 PM, Emre Hasegeli wrote: >>> New versions are attached after the

Re: [PATCH] Improve geometric types

Thank you for taking this. At Thu, 26 Jul 2018 17:12:50 +0200, Tomas Vondra wrote in <672f4c42-6742-c1ec-e9a4-1994b815a...@2ndquadrant.com> > On 07/11/2018 07:13 PM, Emre Hasegeli wrote: > > New versions are attached after the patch got in. I noticed > > tests failing on Windows [1] and added

Re: [PATCH] Improve geometric types

> The version number restriction isn't strictly needed. I only > suggested it because it'd match the #if that wraps the code that's > actually using those macros, introduced by commit cec8394b5ccd. That > was presumably done because versions >= 1800 (= Visual Studio 2013) > have their own

Re: [PATCH] Improve geometric types

On Tue, Jul 10, 2018 at 7:21 AM, Tomas Vondra wrote: > On 06/05/2018 06:32 PM, Emre Hasegeli wrote: >>> Those underscore-prefixed names are defined in Microsoft's >>> [3][4]. So now I'm wondering if win32_port.h needs to >>> #include if (_MSC_VER < 1800). >> >> I don't have the C experience to

Re: [PATCH] Improve geometric types

> Those underscore-prefixed names are defined in Microsoft's > [3][4]. So now I'm wondering if win32_port.h needs to > #include if (_MSC_VER < 1800). I don't have the C experience to decide the correct way. There are currently many .c files that are including float.h conditionally or

Re: [PATCH] Improve geometric types

> But now I'm wondering what does this mean for existing indexes? Doesn't this > effectively mean those are unlikely to give meaningful responses (in the old > or new semantics)? The patches shouldn't cause any change to the indexable operators. The fixes are mostly around the lines and the line

Re: [PATCH] Improve geometric types

On 06/03/2018 11:50 PM, Tom Lane wrote: Tomas Vondra writes: The main remaining question I have is what do do with back-branches. Shall we back-patch this or not? Given the behavioral changes involved, I'd say "no way". That's reinforced by the lack of field complaints; if there were lots

Re: [PATCH] Improve geometric types

Tomas Vondra writes: > The main remaining question I have is what do do with back-branches. > Shall we back-patch this or not? Given the behavioral changes involved, I'd say "no way". That's reinforced by the lack of field complaints; if there were lots of complaints, maybe we'd be willing to

Re: [PATCH] Improve geometric types

Hi Emre, Thanks for the rebased patch. I remember reviewing the patch in the last CF, and it seems in a pretty good shape. I plan to look at it again in the next commitfest, but it seems to have been reviewed by other experienced people so I'm not worried about this part. The main remaining

Re: [PATCH] Improve geometric types

> Thank you for the revised version. This seems fine for me so > marked this as "Ready for Committer". Thank you for bearing with me for longer than year. > By the way I think that line_perp is back patched, could you > propose it for the older versions? (I already marked my entry as > Rejected)

Re: [PATCH] Improve geometric types

Hello, sorry to be late. At Fri, 2 Mar 2018 15:26:25 +0100, Emre Hasegeli wrote in > > Unfortunately according to http://commitfest.cputube.org/ this patch > > doesn't apply anymore. > New versions are

Re: [HACKERS] [PATCH] Improve geometric types

> I'm a bit confused how this patch has gone through several revisions > since, but has been marked as "ready for committer" since 2017-09-05. Am > I missing something? This is floating between commitfests for longer than a year. Aleksander Alekseev set it to "ready for committer", but Kyotaro

Re: [PATCH] Improve geometric types

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested Unfortunately according to http://commitfest.cputube.org/ this patch

Re: [HACKERS] [PATCH] Improve geometric types

Hi, On 2018-02-07 16:46:38 +0100, Emre Hasegeli wrote: > I am incorporating the fix you have posted to the other thread to this patch. You've not posted a version fixing the issues in the surrounding thread, do I see that right? I'm a bit confused how this patch has gone through several

Re: [HACKERS] [PATCH] Improve geometric types

> - line_eq looks too complex in the normal (not containing NANs) >cases. We should avoid such complexity if possible. > >One problem here is that comparison conceals NANness of >operands. Conversely arithmetics propagate it. We can converge >NANness into a number. The attached

Re: [HACKERS] [PATCH] Improve geometric types

Hello, At Wed, 31 Jan 2018 17:33:42 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180131.173342.26333067.horiguchi.kyot...@lab.ntt.co.jp> > 0003: This patch replaces "double" with float and bare arithmetic > and comparisons on double to special

Re: [HACKERS] [PATCH] Improve geometric types

> ! circle_contain_pt() does the following comparison and it > seems to be out of our current policy. > > point_dt(center, point) <= radius > > I suppose this should use FPle. > > FPle(point_dt(center, point), radius) > > The same is true of circle_contain_pt(),

Re: [HACKERS] [PATCH] Improve geometric types

> 1."COPT=-DGEODEBUG make" complains as follows. > > | geo_ops.c:2445:62: error: invalid type argument of unary ‘*’ (have > ‘float8 {aka double}’) > | printf("dist_ppoly_internal- segment 0/n distance is %f\n", *result); Fixing. > 2. line_construct_pm has been renamed to line_construct. I

Re: [HACKERS] [PATCH] Improve geometric types

At Wed, 31 Jan 2018 13:09:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180131.130909.210233873.horiguchi.kyot...@lab.ntt.co.jp> > At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote > in

Re: [HACKERS] [PATCH] Improve geometric types

At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote in > New versions are attached including all changes we discussed. Thanks for the new version. # there's many changes from the previous version..

Re: [HACKERS] [PATCH] Improve geometric types

> I'm fine with the current shape. Thanks. Maybe the same > discussion applies to polygons. (cf. poly_overlap) It indeed does. I am incorporating. > line_closept_point asserts line_interpt_line returns true but it > is hazardous. It is safer if line_closept_point returns NaN if >

Re: [HACKERS] [PATCH] Improve geometric types

Hello, At Thu, 18 Jan 2018 16:01:01 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> 0001: > > - You removed the check of parallelity check of > line_interpt_line(old line_interpt_internal) but line_parallel > is not changed so the consistency between the two functions are > lost. It is better to be another patch file (maybe 0004?). I am making line_parallel() use

Re: [HACKERS] [PATCH] Improve geometric types

Hello, I played more around geometric types and recalled that geometric types don't have orderings. Also have corrected some other misunderstanding. Sorry for my confusion and I think I returned on the way. At Wed, 17 Jan 2018 18:59:30 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> I'm not sure what you mean by the "basic comparison ops" but I'm > fine with the policy, handling each component values in the same > way with float. So point_eq_point() is right and other functions > should follow the same policy. I mean <, >, <= and >= by basic comparison operators.

Re: [HACKERS] [PATCH] Improve geometric types

Hello, I'm still wandering on the way and confused. Sorry for inconsistent comments in advanceX-( At Sun, 14 Jan 2018 13:20:57 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> I found seemingly inconsistent handling of NaN. > > - Old box_same assumed NaN != NaN, but new assumes NaN == > NaN. I'm not sure how the difference is significant out of the > context of sorting, though... There is no box != box operator. If there was one, previous code would return false

Re: [HACKERS] [PATCH] Improve geometric types

Hello, sorry for the absense. (Sorry for the long but should be hard-to-read article..) At Thu, 4 Jan 2018 14:53:47 +0100, Emre Hasegeli wrote in > Rebased versions are attached. Thank you for the new

Re: [HACKERS] [PATCH] Improve geometric types

> Does this patch series fix bug #14971? No, it doesn't. I am trying to improve things without touching the EPSILON.

Re: [HACKERS] [PATCH] Improve geometric types

Does this patch series fix bug #14971? https://www.postgresql.org/message-id/20171213172806.20142.73...@wrigleys.postgresql.org Eric: see https://www.postgresql.org/message-id/CAE2gYzzvp=uvpw4fytoaevyk-wze4jw7u2s1glrok35mr1-...@mail.gmail.com for last version of patch. Motivation for patch is at

Re: [HACKERS] [PATCH] Improve geometric types

On Thu, Nov 30, 2017 at 3:28 AM, Emre Hasegeli wrote: > It would at least be dump-and-restore hazard if we don't let them in. > The new version allows NaNs. > >> This gives a wrong result for NaN-containing objects. > > I removed the NaN aware comparisons from FP macros, and

Re: [HACKERS] [PATCH] Improve geometric types

> dist_pl is changed to take the smaller distance of both ends of > the segment. It seems absorbing error, so it might be better > taking the mean of the two distances. If you have a firm reason > for the change, it is better to be written there, or it might be > better left alone. I am sorry for