Re: Fixing geometic calculation - Mailing list pgsql-hackers

From Paul Matthews
Subject Re: Fixing geometic calculation
Date
Msg-id 4A7CC8A5.3080501@netspace.net.au
Whole thread Raw
In response to Fixing geometic calculation  (Paul Matthews <plm@netspace.net.au>)
Responses Re: Fixing geometic calculation  (Paul Matthews <plm@netspace.net.au>)
List pgsql-hackers
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 all numerical calculations in postgres. And I don't think anyone here
would suggest that doing that, as the results, as per my previous email,
would be immediately and clearly ludicrous.

Yes, floating point arithmetic has built in inaccuracy. However the FP*
macros produce results that are even less accurate than single point
arithmetic, and less accurate than my 25 year old calculator. And if I
could find my slide rule, it could probably do better.

At best, the EPSILON value might have be appropriate for single
precision arithmetic, but in no way is it  appropriate for double
precision arithmetic. Visual C++ defines EPSILON as "The difference
between 1 and smallest value greater than 1". The postgres EPSILON is 10
orders of magnitude greater than the precision supported by the
underlying hardware. This is clearly preposterous.
 EPSILON in postgres is 1.0E-06 EPSILON for floats is 1.19209e-07 EPSILON for doubles is 2.22045E-016




pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: 2nd Call for papers, PostgreSQL Conference
Next
From: Paul Matthews
Date:
Subject: Re: Fixing geometic calculation