From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Emre Hasegeli <emre(at)hasegeli(dot)com> |
Subject: | Re: line_perp() (?-|) is broken. |
Date: | 2018-03-03 00:39:45 |
Message-ID: | 13821.1520037585@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> I happend to see a strange geometric calcualtion on master/HEAD.
> ...
> Instead, calculating inner product of the two direction vectors
> works as expected.
> (l1->A * l2->A) + (l1->B * l2->B) == 0
This seems to be a strict subset of the changes in Emre Hasgeli's
latest geometric-types patch. I'm disinclined to commit it unless
that patch gets rejected, as it'll just require Emre to rebase again.
However, for either patch, I'm a bit concerned about using FPzero()
on the inner product result. To the extent that the EPSILON bound
has any useful meaning at all, it needs to mean a maximum difference
between two coordinate values. The inner product has units of coordinates
squared, so it seems like EPSILON isn't an appropriate threshold there.
Possibly this objection is pointless, because I'm not at all sure that
the existing code is careful about how it uses FPeq/FPzero; perhaps
we're applying EPSILON to all manner of numbers that don't have units
of the coordinate space. But this won't help make it better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-03-03 00:45:13 | Re: [COMMITTERS] pgsql: Add much-more-extensive TAP tests for pgbench. |
Previous Message | Andres Freund | 2018-03-03 00:38:03 | Re: JIT compiling with LLVM v11 |