Hello, I'm returning to here sonn.
I regard Emre's work is aiming to refactor (not improve its
functionality of) the code, on the other hand thins one is a
separate bug fix which also should be backpatched.
But, honestrly I'm not sure such small fix would improve the
current situnation of the geometric operators at any rate.
At Sat, 03 Mar 2018 10:43:26 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in <31399.1520091806@sss.pgh.pa.us>
> Emre Hasegeli <emre@hasegeli.com> writes:
> >> 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.
Agreed.
> > The existing code was probably paying attention to this particular
> > one, but it fails to apply EPSILON meaningfully to many other places.
> > For example lseg_parallel() and lseg_perp() applies it 2 times to the
> > same input. First point_sl() compares x coordinates with FPeq(), and
> > then the returned slopes are compared again with FPeq().
>
> Yeah, comparing a slope to EPSILON sure feels wrong :-(
It is a quite significant problem to fix and would be
controversial in detail. But, anyway, we are focusing on other
points that are less controversial. Then cook the EPSILON in the
next stage.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center