Thread: geo_decls.h oopsie...
These macros are from geo_decls.h:
#define EPSILON 1.0E-06
#ifdef EPSILON
#define FPzero(A) (fabs(A) <= EPSILON)
#define FPeq(A,B) (fabs((A) - (B)) <=
EPSILON)
#define FPne(A,B) (fabs((A) - (B)) >
EPSILON)
#define FPlt(A,B) ((B) - (A) > EPSILON)
#define FPle(A,B) ((A) - (B) <= EPSILON)
#define FPgt(A,B) ((A) - (B) > EPSILON)
#define FPge(A,B) ((B) - (A) <= EPSILON)
#else
#define FPzero(A) ((A) == 0)
#define FPeq(A,B) ((A) == (B))
#define FPne(A,B) ((A) != (B))
#define FPlt(A,B) ((A) < (B))
#define FPle(A,B) ((A) <= (B))
#define FPgt(A,B) ((A) > (B))
#define FPge(A,B) ((A) >= (B))
#endif
But to compare floating point, those are simply wrong. If the values
are both very small or both very large, the method fails.
Here is a more reliable way to make a comparison:
#include <float.h>
double double_compare(double d1, double d2)
{ if (d1 > d2) if ((d1 - d2) < fabs(d1 * DBL_EPSILON)) return 0; else return 1; if
(d1< d2) if ((d2 - d1) < fabs(d2 * DBL_EPSILON)) return 0; else return -1; return 0;
}
float float_compare(float d1, float d2)
{ if (d1 > d2) if ((d1 - d2) < fabs(d1 * FLT_EPSILON)) return 0; else return 1; if
(d1< d2) if ((d2 - d1) < fabs(d2 * FLT_EPSILON)) return 0; else return -1; return 0;
}
All the macros can then be defined in terms of the comparison function.
It's not perfect either, but at least it is better.
"Dann Corbit" <DCorbit@connx.com> writes:
> But to compare floating point, those are simply wrong.
See previous discussions concerning the quality of the builtin geometric
types. Not clear that it's worth worrying about, unless you want to go
in for a wholesale overhaul. My own opinion is that PostGIS will
supersede the need for these types...
> Here is a more reliable way to make a comparison:
Not like that. Perhaps use a fraction of the absolute value of the
one with larger absolute value. As-is it's hard to tell how FLT_EPSILON
is measured.
regards, tom lane
> > But to compare floating point, those are simply wrong.
> See previous discussions concerning the quality of the builtin geometric
> types. Not clear that it's worth worrying about, unless you want to go
> in for a wholesale overhaul. My own opinion is that PostGIS will
> supersede the need for these types...
Oops. I think that we will welcome any updates and fixes to any of the
built in features of PostgreSQL, no matter our individual opinions of
the usefulness of a particular feature (right??). In this case, the
return value patches would seem to be important and the second topic
should be addressed also.
- Thomas
-----Original Message----- From: Thomas Lockhart [mailto:lockhart@fourpalms.org] Sent: Thursday, February 14, 2002 12:22 PM To: Dann Corbit Cc: Tom Lane; Hackers List Subject: Re: geo_decls.h oopsie... > > But to compare floating point, those are simply wrong. > See previous discussions concerning the quality of the builtin geometric > types. Not clear that it's worth worrying about, unless you want to go > in for a wholesale overhaul. My own opinion is that PostGIS will > supersede the need for these types... Oops. I think that we will welcome any updates and fixes to any of the built in features of PostgreSQL, no matter our individual opinions of the usefulness of a particular feature (right??). In this case, the return value patches would seem to be important and the second topic should be addressed also. --------------------------------------------------------------------- Also, the PostGIS is under a far more restrictive license (E.g. I cannot/won't use it.) If fixing a bug is easy, why not fix it? For most tests, there won't be any difference anyway. It is only when the numbers become large or small that differences start to appear. ---------------------------------------------------------------------