Re: Fixing geometic calculation

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing geometic calculation
Date: 2009-08-07 18:43:39
Message-ID: 20090807184339.GO5407@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-08-07 18:48:15 Re: Fixing geometic calculation
Previous Message Heikki Linnakangas 2009-08-07 18:32:30 Re: "PANIC: cannot make new WAL entries during recovery" in the wild