Re: Fixing geometic calculation - Mailing list pgsql-hackers

From Sam Mason
Subject Re: Fixing geometic calculation
Date
Msg-id 20090807184339.GO5407@samason.me.uk
Whole thread Raw
In response to Re: Fixing geometic calculation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
> Sam Mason <sam@samason.me.uk> writes:
> > On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
> >> No, I'm worried about code that supposes that it can divide by (x - y)
> >> after testing that FPeq(x,y) is not true.  point_sl() for instance.
> 
> > OK, but I'm still not sure what you're getting at.
> 
> Underflow.  x!=y does not imply (x-y) != 0, if x and y are sufficiently
> small and close together.  The difference could underflow to zero.

I've just realized why this discussion hasn't been making any sense.
I thought you were talking about correctness of the code with EPSILON
still there and not about what would happen if EPSILON was removed.
Thanks for the patience.

If EPSILON is indeed removed then yes, this will become a problem and
the easiest fix would seem to be to calculate the difference first and
test it explicitly.

The "error accumulation" comment also makes sense now!  Does anyone
know the original use case for using the EPSILON (need some shorthand
for that, a mail client that supports Unicode?) based comparisons so
liberally?  It only makes sense to me if they're done right at the end
of all the calculations, not all the way though.  What defines the "end"
seems up to the user as well, or am I missing something.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: "PANIC: cannot make new WAL entries during recovery" in the wild
Next
From: Greg Stark
Date:
Subject: Re: Fixing geometic calculation