On Sat, Aug 8, 2009 at 3:07 AM, Paul Matthewsp...@netspace.net.au wrote:
IEEE754 does not allow two number X and Y, such that X!=Y and (X-Y)==0.
And since IEEE754 has been around since the 70's or 80's I think we can
start relying on its existence and behavior by now.
You are correct, I
marcin mank wrote:
You are correct, I think, though this does not solve the division problem:
As a first goal I'm just attempting to reduce the EPSILON from 1.0E-6
down to 1.0E-015 (give or take). The current regression test suite works
fine down to 1.0E-09. At 1.0E-10 errors appear, not in
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
Let us consider the ordering of real numbers in postgres. As you can see
from
the results below it has clearly returned the correct results.
select( 1. = 1.0002 ); = f
select( 1.
On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
Let us consider the ordering of real numbers in postgres. As you can see
from
the results below it has clearly returned the correct results.
select(
On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
We have two points with a finite separation in the x axis.
Postgres thinks they are not the
On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
We have two points with a finite
Sam Mason s...@samason.me.uk writes:
I would agree with Paul that EPSILON is a hack and probably should be
removed.
It's a hack but it's dealing with an extremely real problem, namely
the built-in inaccuracy of floating-point arithmetic. You can't just
close your eyes to that and hope that
On Fri, Aug 07, 2009 at 10:29:27AM -0500, Kenneth Marshall wrote:
On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
points in PG [..] don't
arbitrarily go jumping off millions of miles away or being annihilated
by their anti-particle just because it's possible.
It was definitely
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
I would agree with Paul that EPSILON is a hack and probably should be
removed.
It's a hack but it's dealing with an extremely real problem, namely
the built-in inaccuracy of floating-point
Sam Mason s...@samason.me.uk writes:
Sorry, I'm struggling to parse that. I think it's all the double
negatives. Are you saying that HYPOT() should really return zero when
it's currently giving back would be FPzero?
No, I'm worried about code that supposes that it can divide by (x - y)
after
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
Sorry, I'm struggling to parse that. I think it's all the double
negatives. Are you saying that HYPOT() should really return zero when
it's currently giving back would be FPzero?
No, I'm
Sam Mason s...@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.
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
Sam Mason s...@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.
On Fri, Aug 7, 2009 at 7:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Sam Mason s...@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
On Fri, Aug 07, 2009 at 07:48:15PM +0100, Greg Stark wrote:
On Fri, Aug 7, 2009 at 7:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
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.
Actually I don't think
Tom Lane wrote:
It's a hack but it's dealing with an extremely real problem, namely
the built-in inaccuracy of floating-point arithmetic. You can't just
close your eyes to that and hope that everything will be okay.
If the above statement was true, then the FP* macros should be extended
to
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.
We could perhaps fix those specific issues by testing the difference
explicitly instead of doing it like that. But there's still the
Paul Matthews wrote:
EPSILON in postgres is 1.0E-06
EPSILON for floats is 1.19209e-07
EPSILON for doubles is 2.22045E-016
Bad form to reply to my own post and all. If EPSILON for double
represented 1mm, then postgres is rounding to the nearest 10,000,000 km.
Since its only about
18 matches
Mail list logo
