Things to do

Previous: User interface Up: Final report on the Algebra Assistant Next: References

Things to do

The selection mechanism as described has only just been finished, and somewhat debugged. It has not been used enough to be sure that it doesn't crash on a given input, and that it does what was intended for all inputs. It is possible that it does what it was programmed to do for a given case, but that isn't the right thing. A lot of the problems in building the user interface was simply in deciding what kinds of things needed to be possible and what resources were needed to make them possible.

The polynomial representation is missing of quite a number of objects: equations, subtractions, exponents to name but a few. The mechanism to build these is there, the work just has to be done.

Although selection and substitution is expected to be very central to the system, a lot of other more sundry facilities are needed. An undo button for instance is required. More generally, a history mechanism, and a way to annotate the history would prove very useful if a derivation done by one person is to be understood by another person.

Any history mechanism must also be able to deal with several sets of somewhat unrelated equations, not all of which might be on the screen at the same time. The notion of a workspace is borrowed from APL, and the concept of saving the entire workspace to a file, separate from whatever it was built upon is needed. It should also be possible to refer to equations in other workspaces: for instance, one might build a workspace full of useful trigonometric identities, or while doing a problem in quantum mechanics a workspace full of the fundamental postulates would be included into a workspace dedicated to that problem. The possibilities go on and on.

A suggestion facility is needed. An interface to Maple or Mathematica should be fairly simple to build: a primitive could be written to fork and exec a copy of Maple or Mathematica, connecting its standard I/O ports to a bidirectional pipe. Equations and commands would then just be sent down the pipe, and responses would be received.

When the user asks for a reduction suggestion, the equation would be sent to Mathematica/Maple with a command to do one step of simplification and the results parsed back into an equation and displayed.