Re: Coordinates of closest points on a pair of skew lines

Dave Eberly wrote:
"Kenneth Sloan" <KennethRSloan@xxxxxxxxx> wrote in message news:fcl3c6$tva$1@xxxxxxxxxxxxxxxxxxxxxxxx
yes...but I'm still interested in this "theory" you spoke of.

What is your problem?

The "theory" is that you have points on a plane that was
defined mathematically.

My point was that your example points were not "defined mathematically" - or at least not defined using Real numbers.

There *is* a theory of floating point computation - and it does NOT predict that the points generated will lie on a plane (unless you re-think what it means for a floating point number to lie in a plane).

It was the same point you were making - but adding the point that you yourself fell into the same trap that you were warning others against.


With real-number arithmetic, the
random points you generate all lie in the plane.

You didn't specify real number arithmetic. You specified floating point, and then tried to invoke a "theory" about Reals.

In "theory",
the convex hull of the points is a planar polygon.

No. In "theory" the convex hull of a set of points generated by your method, using floating point arithmetic, is NOT (necessarily) a planar polygon.

With
floating-point arithmetic you get errors.

Now it becomes interesting. "Errors" is a loaded term. I wouldn't go so far as to call them errors. I prefer to think in terms of a theory that frankly accepts floating point model numbers and then re-thinks what it means to be "in a plane".

I like to reserve "error" to mean "it was possible to write down a more exact answer - but for some reason you failed to do so". But, this is a minor point and it would be an error to pursue it.

I apologize if this point of view is "annoying" to you. Perhaps it would be easier for you to simply ignore me.

Switching to
rational arithmetic at this time will produce a hull that is
(most likely) not a planar polygon.

Almost certainly not a planar polygon. At least we agree that switching to rational arithmetic HERE is a bad idea. I'm not particularly convinced that rational arithmetic is a great idea - but if you are going to use it, then you need to "switch" to rational arithmetic BEFORE YOU LEAVE the rationals. My point was - perhaps (for some folk) it makes sense to instead re-think how geometry works with floating point numbers.

After all, if you restrict yourself to rational numbers you run into a couple of earth-shattering problems eventually...don't you?

For example: if I take the point <1,1> in the x,y plane and want to rotate it about the origin so that it lies on the x-axis, how does exact rational arithmetic help me? The answer is: <x,0> - but what is 'x'?

My personal take on this generic argument is that exact rational arithmetic is fine for folk who want to do combinatorics and call it geometry, but that for real geometry floating point is LESS of a concession (compared to the ideal of using real Reals) than "exact rational arithmetic".

BOTH require adjustments - but for some reason the necessary adjustments seem to me to be more obvious and (sometimes) easier to make with floating point.




Allow me to speculate that you are just trying to be annoying.
How typical.


You are free to speculate, but I don't see the point in ad hominem comments.

I freely admit that I'm often annoying, without even trying.

One final question: if you use floating point arithmetic exclusively (I'll allow both single- and double-precision, use them in any way that seems appropriate), what is a principled way of determining if a "point" (<x,y,z> triple where x, y, and z are floating point numbers) is in a "plane" (a secondary question might be: what's the best representation for a "plane", given that you are resticted to floating point numbers.


Now...try the same exercise, restricting yourself to the rationals.

Finally...try to use your two solutions to solve real geometric problems.


--
Kenneth Sloan KennethRSloan@xxxxxxxxx
Computer and Information Sciences +1-205-932-2213
University of Alabama at Birmingham FAX +1-205-934-5473
Birmingham, AL 35294-1170 http://www.cis.uab.edu/sloan/
.

Relevant Pages

  • Re: Find out if I/10^i = J/2^j (decadic - dyadic pairing)
    ... 0s with different valency towards infinity; ... but instead some sort of floating point number. ... The reals are sometimes ... algorithms that /do/ halt with the output of a symbol (marks on tape, ...
    (sci.math)
  • Re: Float comparison
    ... If you exclude NaNs and infinities it is a member of a finite subset of the rationals, which in turn is a subset of the reals. ... Now quote the section of the C standard that states that floating point numbers are reals. ... can tell the exact value stored in that object. ... The intervening calculations were approximations which gave a known acceptable limit on the error of the settings given to the hardware when compared to the theoretical mathematical values the algorithm I had to implement an approximation of. ...
    (comp.lang.c)
  • Re: Floating point errors in collision routines
    ... > Trying to converge a floating point calculation all the way to ... > zero is fundamentally futile. ... > Newer collision engines, like Gino's SOLID, get ... >> the plane.) ...
    (comp.lang.cpp)
  • Re: Standard integer types vs types
    ... making claims like "the reals are a superset of the rationals". ... the rationals are equivalence classes over ordered ... it's trivial to find an integer type and a floating point type such ...
    (comp.lang.c)
  • Re: Float comparison
    ... value cannot represent ANY floating value, ... to say that the integer 3 represents the interval of reals ... [2.5, 3.5) or [3,4) as it does to say that the float represents ... IEEE floating point values are able to contain a subset ...
    (comp.lang.c)
Loading