.bp
.H 1 "Design objectives"
.sp
.P
The design objectives for knotEd 
were to supply the user with an easy way to draw and alter a knot.  By drawing
a knot we mean to enter a knot into the computer in such a way so that the user
can control the appearance and at the same time the computer understands
the semantics of
the knot being drawn.  This is the main point of departure for knotEd from
graphic editors like gremlin, xfig and others.  If the software knows what
knot the user has drawn it can automatically generate the sentence describing
the knot (as discussed in section 1) which can then be taken into programs
that automatically calculate invariants.  For a human to generate the sentence
from a diagram is both tedious and error prone and many of the algorithms
for calculating invariants require time exponential in the number of crossings
in a diagram.  Programs to calculate invariants (and other things) from 
a sentence have been developed by several graduate students and professors
of the University of California at Berkeley.  knotEd has been used in 
conjunction with several of them.  It is the intent of the author that if 
knotEd is released to the mathematics community that it should be bundled
and integrate with these programs (some of the algorithms are extremely
sophisticated).  Another feature that could leverage off a program that knew
what knot a user's diagram represented is an idea call an isotopy lock.  A user
could activate the lock and from then on the program would only allow
alterations to the knot that were obviously reducible to a sequence of
Reidemeister moves.  Thus the knot editor could be used as an intelligent
chalk board for educational purposes, or if the user saved all of the
intermediate diagrams the editor could automate some aspects of demonstrating
the equivalence of two knots.  Thus an automated illustrator would lead
to a semi automated theorem prover (in the limited realm of knot theory).
Additional applications envisioned for the knot editor include aiding in the
preparation of papers (all diagrams in this paper were produced by knotEd)
and also as a teaching aid.
.P
The biggest question was how the program should interact with the user.
Several different operating metaphors were considered, the one finally
settled on we call "non-physical".  This name is derived from the fact that
many of the models brought forth involved realistic 3 dimensional perspective
and physics.  One of the most popular with the electrostatic model where
a knot would be thought of as being a collection of rigid tubes sitting in
3-space with balls where they joined.  The balls would carry electrostatic
charges and the tubes ends could move around on the surface of the balls. 
The configuration would then move around or "relax" until it had reached the
lowest energy configuration and would thus (when drawn in perspective) give
a "pleasant" looking knot.   The user could change his view point and alter
the knot by removing a sequence of tubes and replacing them with another.
The major drawbacks of this hypothetical model were the computation,
the difficulty the user would encounter in specifying a path in 3-space and
the dependence on so much of knot theory on actual diagrams.  As discussed
in section 1 a knot is reduced to a sentence by examining the crossings on
its diagram.  But a knot sitting in three space has no crossings, the lines
appear to cross on our 2 dimensional projections but never cross in 3-space.
It was felt that with the given resources it would be impossible to implement
such a model and to do so would be contrary to how knots are thought of
in mathematics (thus making the program a burden instead of a tool).
.P
Another model considered was a two plan model.  Again the knot would be 
thought as ball and pipe affair but this time all of the pipes would be
trapped in two planes (one slightly above the other)  with vertical rods
connecting the pipes in the two planes.  The user would then specify which
pipes were to be attached where.  This combined a physical realization of
knot in 3-space with the diagrams because the program could associate a unique
diagram with the tubeworks by viewing the knot from above.  This model
does not seem to have any major defects except that specifying pipes could
become quite tedious.
.P
The model selected was derived by reading numerous books and articles on knots
and observing how diagrams were drawn freehand and what properties of diagrams
were actually used in theorems.  As alluded to before the 3-space realization
of a knot is of little use when working on a knot.  The important relationship
is not between a diagram and its 3-space realization but between the
diagram and its sentence.  The diagram should serve as an aid in altering 
the knot sentence.  In keeping with this the knot is realized in knotEd
as a graph with vertices that all join either 2 or 4 edges.  The 2 valent
vertices are called control points (the user may add, delete or move them
around) and the 4 valent vertices are the crossings (they can be thought
of as vertices that have additional state information as to which edge
passes over and which edge passes under).  The user can remove, move, or
replace any sequence of control points and the program will then automatically
place the crossings in the correct locations.  Then the program tries to
associate these new crossings with the one in the previous knot so that
they can inherit the state (which edge is up etc) from them.  The user
can imaging that the edges are passing over and under (like in the pipe
model) but is not troubled about details in fitting them together. 
.P
What the user actually sees while working is exactly like the diagrams in 
this paper (knotEd is a what you see is what you get program).  Though
the user can turn on additional display features (such as marking control
points,
etc).  The next drawing shows a knot as the user of the program
might see it while working on it.  The boxes represent the control points
and the dotted lines represent the actual lines of the diagram.  The knot
is based off these lines and not the smooth curves because finding the 
intersections of these curves would involve solving simultaneous 3rd degree
polynomials (possible but extremely messy).  As you can see the program often
generates a handsome diagram from a small number of control points.
.sp
.DS
.PS
.so noisy.pic
] with .nw at (2,0)
.PE
.DE
