Re: Fixing geometic calculation

From: Paul Matthews <plm(at)netspace(dot)net(dot)au>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing geometic calculation
Date: 2009-08-08 00:36:53
Message-ID: 4A7CC8A5.3080501@netspace.net.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Matthews 2009-08-08 01:07:38 Re: Fixing geometic calculation
Previous Message Herodotos Herodotou 2009-08-08 00:34:06 Re: Join optimization for inheritance tables