On Fri, Aug 07, 2009 at 04:16:56PM +0100, Sam Mason wrote:
> On Fri, Aug 07, 2009 at 09:49:41AM -0500, Kenneth Marshall wrote:
> > On Fri, Aug 07, 2009 at 09:12:34AM -0500, Kenneth Marshall wrote:
> > > On Fri, Aug 07, 2009 at 11:29:47PM +1000, Paul Matthews wrote:
> > > > We have two points with a finite separation in the x axis.
> > > > Postgres thinks they are not the same point, nor one left of the
> > > > other, nor to the right. This is clearly a both a physical and
> > > > logical impossibility.
> >
> > Actually, quantum theory will allow this to happen. :)
>
> I'm not a physicist, but I don't think it does. QM defines the
> probability distribution within which the particle will be found. Once
> you've actually observed both "points" you will know their physical
> relation--you'll also have given them energy them so next time you look
> they'll be somewhere else, but the act of observation causes the above
> distribution to be collapsed. This sidesteps the whole issue of the
> fact that points in PG are defined in euclidean space and do indeed
> have a definite location and can be compared at all times---they don't
> arbitrarily go jumping off millions of miles away or being annihilated
> by their anti-particle just because it's possible.
>
> I would agree with Paul that EPSILON is a hack and probably should be
> removed. However it will cause user visible changes so it's not quite
> as simple as that to change. I don't have anything really very useful
> to add apart from saying that maybe the default should be the other way
> around?
>
> --
> Sam http://samason.me.uk/
>
It was definitely a tongue-in-cheek response since QT is not really
a topic for this mailing list. However, removing EPSILON completely
is not a good idea for the exact reason it was included originally.
Floating point numbers are approximations and since their precision
is neccessarily limited this fact must be included in any calculation
using them. I do agree that hard-coding it to a value that does not
reflect the reality of the calculation is not good. It would be
better to have a GUC to allow it to be specified than to have it
be zero. Maybe one setting would allow the system to calculate the
appropriate value for EPSILON based on the hardward. One way to
address the duplicity issue is to define for yourself what it means
if a point is both inside and outside, i.e. in this case the point
is always defined to be inside or the point is always defined to
be outside.
Regards,
Ken
