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 Sat, Aug 8, 2009 at 3:07 AM, Paul Matthews 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 think, though this do
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 38
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
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
On Fri, Aug 07, 2009 at 07:48:15PM +0100, Greg Stark wrote:
> On Fri, Aug 7, 2009 at 7:13 PM, Tom Lane 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 subtraction ca
On Fri, Aug 7, 2009 at 7:13 PM, Tom Lane wrote:
> Sam Mason 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
On Fri, Aug 07, 2009 at 02:13:26PM -0400, Tom Lane wrote:
> Sam Mason 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
Sam Mason 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 doe
On Fri, Aug 07, 2009 at 12:50:39PM -0400, Tom Lane wrote:
> Sam Mason 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
Sam Mason 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 testing that FP
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
> Sam Mason 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
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 defi
Sam Mason 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 everything will be o
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
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 no
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.
> >
> > sele
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.
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. < 1.0002 ); => t
select( 1. > 1.
19 matches
Mail list logo
