Thread: Re: [PATCHES] guc

Peter Eisentraut <peter_e@gmx.net> writes:
> Actually, I just took a peak into include/utils/geo_decls.h, and the
> definiton of EPSILON at the top leaves me to think that printing out
> anything more than 6 significant digits is nonsense anyway. Numerical
> analysts would probably shudder.

Indeed.  Does that mean you'd be happy with restricting the number of
digits printed for geometrical types only?
        regards, tom lane

Tom Lane writes:

> Indeed.  Does that mean you'd be happy with restricting the number of
> digits printed for geometrical types only?

Not really.  I'd much rather see the EPSILON removed/revised.  I don't
claim to understand numerical analysis, but that thing is completely
bogus.  I can see how the error would be controllable when you just add
numbers, but once you start multiplying or run trigonometric functions, a
fixed epsilon just doesn't cut it.

If you want to limit the number of digits, why not just reimplement the
geometric types as single precision?

And if we think that an epsilon-based float comparison is important, why
don't we do it everywhere?

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Not really.  I'd much rather see the EPSILON removed/revised.  I don't
> claim to understand numerical analysis, but that thing is completely
> bogus.

Yeah, and there's even the handy comment:
*      XXX These routines were not written by a numerical analyst.

to remind you that this stuff was written by someone who was studying
databases not numerical analysis.

In my eyes, all of our geometric datatypes are firmly in the "academic
toy prototype" category.  They could use a thorough overhaul, but in
view of the existence of the PostGIS project I doubt they'll ever get
one.  Anyone who might have both the ability and the motivation to
improve these datatypes will probably go use/work on PostGIS instead.

I could make an argument that we should just yank these types from the
distribution and leave the field clear for PostGIS.  I don't really want
to take that line; the types do have usefulness for simple applications,
and what's probably more important is they help keep us honest on
datatype extensibility concerns.  But I have a hard time justifying
spending any core development time on them.

Basically what I want is some fairly simple answer that will let us stop
wasting quite so much maintenance effort on the geometry regression
test.  Because, frankly, that code is nowhere near good enough to
justify our expending much time on it.

In that context, trimming the number of displayed decimal places seems
like a great solution.  Whether it's the "right thing" from a purist's
viewpoint doesn't concern me a whole lot.
        regards, tom lane