Re: Fixing geometic calculation

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

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 380,000 km to the moon it's a good thing <diety of
choice> does not use postgres.