Re: Proposal for the geometric engine, RFC

[Dylan Paul Thurston <dpt@math.berkeley.edu>]

On Mon, Mar 13, 2000 at 08:56:29PM +0800, Hilaire Fernandes wrote:
> 1. There is 3 base objects: point, curve and vector all derived from
> an abstract object geometricObject
> 
> 	a. derivated form basic point object we have: free point on a
> plane, free point on a curve, intersection points and transformed
> point. ...
> 	b. derivated from curve object we have: line, half-line,
> segment, circle, arc circle and locus. The transformed representation
> of this object and variant representation (ex: a line can be defined
> by two points, a point and a line (parallel or perpendicular) can be
> represented by this classes, ...

I don't know anything about the internals of Dr Genius, but why the
asymmetry in these two cases?  Mathematically, points and lines in the
plane have almost the same structure, so, for instance, a point
defined by the intersection of two lines is dual to a line defined by
two points, and a point on a curve is dual to a tangent to the curve.
This is called projective duality.

Hmm.  I suppose it's a user interface reason.  It's easy to specify a
free point with the mouse, and harder to specify a free line.  I would
like to see this duality reflected more in the interface, though, I
think it should be doable.  If I want to draw an arbitrary line
through a point, I currently have to pick another point arbitrarily
and draw the line passing through the two points; why should I have to
specify the second point?

Here's another way of saying what I want: currently, points can have 0
[intersection], 1 [on curve], or 2 [free] degrees of freedom, while
all curves/lines have 0 degrees of freedom.  Why not have lines with 1
degree of freedom (such as: passing through a given point; tangent to
a given circle/geometric locus; parallel to a given line)?  2 degrees
of freedom would also be nice if there were a good interface, but I
can't think of one off the top of my head.

Another, more minor request (that's maybe not related to the geometric
engine): currently, macros seem to require more parameters than they
really should.  This seems to be caused by two factors:
(a) Inability to, for instance, get the endpoints of a segment from
    the segment.  This means that I sometime have to select both a
    segment and one of its endpoints; in practice, I end up making the
    two endpoints the parameters.
(b) It would be really nice if there were a way to specify "global
    parameters" to macros, so that it would be easy to draw a bunch of
    circles of the same size, for instance.
In general, macros are a little bit too rigid, and it would be nice
to, for instance, be able to name the parameters.

Another hard request for the geometric engine: can you add ideal
points at infinity?

When you get to working on the UI some more, it would be really nice
to be able to make construction lines that can be hid and shown
easily.  I don't know how to do this other than turning the
construction lines white.  A good UI for this is to use drawing
layers.

> 2. A new objet: coordinate referential is added; it is composed of one
> point and two vector (probably three points can be an additional
> possibility to build it)

The English term is "reference frame".  This is a good idea, but maybe
it's a special case of some more general construction (involving
global parameters to macros??)  I'll think about it.
 
> 3. Each geometric object depends on a coordinate referential, so the
> object coordinate are relative to one referential. This allows
> teaching this topic. Technically this mean the geomtricObject
> contained a reference to a coordinate referential. There is a
> mechanism to change the referential attached to one obcjet

What is the base reference frame defined with respect to?

When you change the reference frame of an object, does the object move
or not?

This feature would allow drawing three dimensional pictures very
easily, which would be quite nice.


Another thing to think about when working on the geometric engine is
what varies when you move a constructed object.  It would be nice to
be able to pin down some of the objects so that they don't move when
you move objects constructed from them.  This would allow to, eg,
trivially construct mechanical linkages (see
http://www.ma.huji.ac.il/~deldar/thesis/default.htm).  This probably
affects the geometric engine: you need to know whether an object is
mobile or not, either because it's been marked as immobile or because
all of its parents are immobile.


There are several ideas here, some of them probably silly.  I'm happy
to explain them more and think about implementation more seriously.

Best Regards (and thanks for a great program!),
	Dylan Thurston