doc: Extend comments on coordinatization; add a theory.md notes file

notes/design.md

@@ -51,3 +51,9 @@ In general it seems in 3D it's more comfortable to represent planes and points t
 * A plane through the origin and a point on it. The line is perpendicular to that plane and goes through that point. This representation at least seems to be 1-1. Easy to tell if lines are parallel. Maybe not as easy to tell if they intersect, but not particularly worse than pairs of points, for example.
 
 * The unit normal vector of the plane from the last option, but projected to the xy-plane, and that point of intersection, but projected to the xy-plane, so that there are just four numbers corresponding to the four-dimensionality of the space of lines. This representation has some discontinuities: very close lines might be represented by faraway coordinates, and (partly as a result) it might be tricky to compute with in general.
+
+###### Choice of coordinatization
+
+Note that ultimately the choice of coordinates for entities serves solely to facilitate (a) display and manipulation of geometric objects, and (b) expressing and solving the constraints that are put on those entities. So we want to steer toward the choices that make those tasks the easiest. We won't necessarily have direct coordinates for every type of entity that Dyna3 allows to be created. Some may be "derived entities" that serve only as "front ends" for the actual items that Dyna3's internals are processing. For example, suppose we choose a system that provides direct parametrizations of spheres and planes (see e.g. [inversive.md](inversive.md)). Perhaps then when the user creates a circle, Dyna3 will actually create an auxiliary sphere and plane, and the auxiliary constraint that the plane contains the center of the circle. These auxiliaries would be marked so that only their intersection would be displayed, producing an arbitrary circle.
+
+The sort of scheme outlined in the previous paragraph works particularly well when it is easy to express the sorts of constraints one wants on the derived entity in terms of the supported constraints on the auxiliary entities. So for example, we want to be able to constrain a circle to contain a given point -- that translates just to both the plane and the sphere contain that point, so that works well. We also want to be able to say that a line and circle are tangent. This translates to the line being in the associated plane (easily expressed) and then (as one possibility) that there is a second plane containing the line and perpendicular to the first plane and tangent to the sphere. So at least for those two examples, these underlying entities to represent circles seem to work fairly well.