Network Working Group D. Arnon
Request for Comments: 1019 Xerox PARC
September 1987
Report of the Workshop on Environments for Computational Mathematics
July 30, 1987
ACM SIGGRAPH Conference
Anaheim Convention Center, Anaheim, California
Status of This Memo
This memo is a report on the discussion of the representation of
equations in a workshop at the ACM SIGGRAPH Conference held in
Anaheim, California on 30 July 1987. Distribution of this memo is
unlimited.
Introduction
Since the 1950's, many researchers have worked to realize the vision
of natural and powerful computer systems for interactive mathematical
work. Nowadays this vision can be expressed as the goal of an
integrated system for symbolic, numerical, graphical, and
documentational mathematical work. Recently the development of
personal computers (with high resolution screens, window systems, and
mice), high-speed networks, electronic mail, and electronic
publishing, have created a technological base that is more than
adequate for the realization of such systems. However, the growth of
separate Mathematical Typesetting, Multimedia Electronic Mail,
Numerical Computation, and Computer Algebra communities, each with
its own conventions, threatens to prevent these systems from being
built.
To be specific, little thought has been given to unifying the
different expression representations currently used in the different
communities. This must take place if there is to be interchange of
mathematical expressions among Document, Display, and Computation
systems. Also, tools that are wanted in several communities (e.g.,
WYSIWYG mathematical expression editors), are being built
independently by each, with little awareness of the duplication of
effort that thereby occurs. Worst of all, the ample opportunities
for cross-fertilization among the different communities are not being
exploited. For example, some Computer Algebra systems explicitly
associate a type with a mathematical expression (e.g., 3 x 3 matrix
of polynomials with complex number coefficients), which could enable
automated math proofreaders, analogous to spelling checkers.
The goal of the Workshop on Environments for Computational
Mathematics was to open a dialogue among representatives of the
Arnon [Page 1]
RFC 1019 September 1987
Computer Algebra, Numerical Computation, Multimedia Electronic Mail,
and Mathematical Typesetting communities. In July 1986, during the
Computers and Mathematics Conference at Stanford University, a subset
of this year's participants met at Xerox PARC to discuss User
Interfaces for Computer Algebra Systems. This group agreed to hold
future meetings, of which the present Workshop is the first. Alan
Katz's recent essay, "Issues in Defining an Equations Representation
Standard", RFC-1003, DDN Network Information Center, March 1987
(reprinted in the ACM SIGSAM Bulletin May 1987, pp. 19-24),
influenced the discussion at the Workshop, especially since it
discusses the interchange of mathematical expressions.
This report does not aim to be a transcript of the Workshop, but
rather tries to extract the major points upon which (in the Editor's
view) rough consensus was reached. It is the Editor's view that the
Workshop discussion can be summarized in the form of a basic
architecture for "Standard Mathematical Systems", presented in
Section II below. Meeting participants seemed to agree that: (1)
existing mathematical systems should be augmented or modified to
conform to this architecture, and (2) future systems should be built
in accordance with it.
The Talks and Panel-Audience discussions at the Workshop were
videotaped. Currently, these tapes are being edited for submission
to the SIGGRAPH Video Review, to form a "Video Proceedings". If
accepted by SIGGRAPH, the Video Proceedings will be publicly
available for a nominal distribution charge.
One aspect of the mathematical systems vision that we explicitly left
out of this Workshop is the question of "intelligence" in
mathematical systems. This has been a powerful motivation to systems
builders since the early days. Despite its importance, we do not
expect intelligent behavior in mathematical systems to be realized in
the short term, and so we leave it aside. Computer Assisted
Instruction for mathematics also lies beyond the scope of the
Workshop. And although it might have been appropriate to invite
representatives of the Spreadsheets and Graphics communities, we did
not. Many of those who were at the Workshop have given considerable
thought to Spreadsheets and Graphics in mathematical systems.
Financial support from the Xerox Corporation for AudioVisual
equipment rental at SIGGRAPH is gratefully acknowledged. Thanks are
due to Kevin McIsaac for serving as chief cameraman, providing
critical comments on this report, and contributing in diverse other
ways to the Workshop. Thanks also to Richard Fateman, Michael
Spivak, and Neil Soiffer for critical comments on this report.
Subhana Menis and Erin Foley have helped with logistics and
documentation at several points along the way.
Information on the Video Proceedings, and any other aspect of the
Workshop can be obtained from the author of this report.
Arnon [Page 2]
RFC 1019 September 1987
I. Particulars of the meeting
The Workshop had four parts: (1) Talks, (2) Panel Discussion, (3)
Panel and Audience discussion, (4) and Live demos. Only a few of the
systems presented in the talks were demonstrated live. However, many
of the talks contained videotapes of the systems being discussed.
The talks, each 15 minutes in length, were:
1. "The MathCad System: a Graphical Interface for Computer
Mathematics", Richard Smaby, MathSOFT Inc.
2. "MATLAB - an Interactive Matrix Laboratory", Cleve Moler,
MathWorks Inc.
3. "Milo: A Macintosh System for Students", Ron Avitzur, Free Lance
Developer, Palo Alto, CA.
4. "MathScribe: A User Interface for Computer Algebra systems", Neil
Soiffer, Tektronix Labs.
5. "INFOR: an Interactive WYSIWYG System for Technical Text",
William Schelter, University of Texas.
6. "Iris User Interface for Computer Algebra Systems", Benton Leong,
University of Waterloo.
7. "CaminoReal: A Direct Manipulation Style User Interface for
Mathematical Software", Dennis Arnon, Xerox PARC.
8. "Domain-Driven Expression Display in Scratchpad II", Stephen
Watt, IBM Yorktown Heights.
9. "Internal and External Representations of Valid Mathematical
Reasoning", Tryg Ager, Stanford University.
10. "Presentation and Interchange of Mathematical Expressions in the
Andrew System", Maria Wadlow, Carnegie-Mellon University.
The Panel discussion lasted 45 minutes. The panelists were:
Richard Fateman, University of California at Berkeley
Richard Jenks, IBM Yorktown Heights
Michael Spivak, Personal TeX
Ronald Whitney, American Mathematical Society
Arnon [Page 3]
RFC 1019 September 1987
The panelists were asked to consider the following issues in planning
their presentations:
1. Should we try to build integrated documentation/computation
systems?
2. WYSIWYG editing of mathematical expressions.
3. Interchange representation of mathematics.
4. User interface design for integrated documentation/computation
systems.
5. Coping with large mathematical expressions.
A Panel-Audience discussion lasted another 45 minutes, and the Demos
lasted about one hour.
Other Workshop participants, besides those named above, included:
S. Kamal Abdali, Tektronix Labs
George Allen, Design Science
Alan Katz, Information Sciences Institute
J. Robert Cooke, Cornell University and Cooke Publications
Larry Lesser, Inference Corporation
Tom Libert, University of Michigan
Kevin McIsaac, Xerox PARC and University of Western Australia
Elizabeth Ralston, Inference Corporation
II. Standard Mathematical Systems - a Proposed Architecture
We postulate that there is an "Abstract Syntax" for any mathematical
expression. A piece of Abstract Syntax consists of an Operator and
an (ordered) list of Arguments, where each Argument is (recursively)
a piece of Abstract Syntax. Functional Notation, Lisp SExpressions,
Directed Acyclic Graphs, and N-ary Trees are equivalent
representations of Abstract Syntax, in the sense of being equally
expressive, although one or another might be considered preferable
from the standpoint of computation and algorithms. For example, the
functional expression "Plus[Times[a,b],c]" represents the Abstract
Syntax of an expression that would commonly be written "a*b+c".
A "Standard Mathematical Component" (abbreviated SMC) is a collection
of software and hardware modules, with a single function, which if it
reads mathematical expressions, reads them as Abstract Syntax, and if
it writes mathematical expressions, writes them as Abstract Syntax.
A "Standard Mathematical System" (abbreviated SMS) is a collection of
SMC's which are used together, and which communicate with each other
in Abstract Syntax.
We identify at least four possible types of components in an SMS.
Arnon [Page 4]
RFC 1019 September 1987
Any particular SMS may have zero, one, or several instances of each
component type. The connection between two particular components of
an SMS, of whatever type, is via Abstract Syntax passed over a "wire"
joining them.
1) EDs - Math Editors
These edit Abstract Syntax to Abstract Syntax. A particular system
may have editors that work on some other representations of
mathematics (e.g., bitmaps, or particular formatting languages),
however they do not qualify as an ED components of a SMS. An ED may
be WYSIWYG or language-oriented.
2) DISPs - Math Displayers
These are suites of software packages, device drivers, and hardware
devices that take in an expr in Abstract Syntax and render it. For
example, (1) the combination of an Abstract Syntax->TeX translator,
TeX itself, and a printer, or (2) a plotting package plus a plotting
device. A DISP component may or may not support "pointing" (i.e.,
selection), within an expression it has displayed, fix a printer
probably doesn't, but terminal screen may. If pointing is supported,
then a DISP component must be able to pass back the selected
subexpression(s) in Abstract Syntax. We are not attempting here to
foresee, or limit, the selection mechanisms that different DISPs may
offer, but only to require that a DISP be able to communicate its
selections in Abstract Syntax.
3) COMPs - Computation systems
Examples are Numerical Libraries and Computer Algebra systems. There
are questions as to the state of a COMP component at the time it
receives an expression. For example, what global flags are set, or
what previous expressions have been computed that the current
expression may refer to. However, we don't delve into these hard
issues at this time.
4) DOCs - Document systems
These are what would typically called "text editors", "document
editors", or "electronic mail systems". We are interested in their
handling of math expressions. In reality, they manage other document
constituents as well (e.g., text and graphics). The design of the
user interface for the interaction of math, text, and graphics is a
nontrivial problem, and will doubtless be the subject of further
research.
A typical SMS will have an ED and a DISP that are much more closely
coupled than is suggested here. For example, the ED's internal
representation of Abstract Syntax, and the DISP's internal
representation (e.g., a tree of boxes), may have pointers back and
Arnon [Page 5]
RFC 1019 September 1987
forth, or perhaps may even share a common data structure. This is
acceptable, but it should always be possible to access the two
components in the canonical, decoupled way. For example, the ED
should be able to receive a standard Abstract Syntax representation
for an expression, plus an editing command in Abstract Syntax (e.g.,
Edit[expr, cmd]), and return an Abstract Syntax representation for
the result. Similarly, the DISP should be able to receive Abstract
Syntax over the wire and display it, and if it supports pointing, be
able to return selected subexpressions in Abstract Syntax.
The boundaries between the component types are not hard and fast. For
example, an ED might support simple computations (e.g.,
simplification, rearrangement of subexpressions, arithmetic), or a
DOC might contain a facility for displaying mathematical expressions.
The key thing for a given module to qualify as an SMC is its ability
to read and write Abstract Syntax.
III. Recommendations and Qualifications
1. It is our hypothesis that it will be feasible to encode a rich
variety of other languages in Abstract Syntax, for example,
programming constructs. Thus we intend it to be possible to
pass such things as Lisp formatting programs, plot programs,
TeX macros, etc. over the wire in Abstract Syntax. We also
hypothesize that it will be possible to encode all present and
future mathematical notations in Abstract Syntax (e.g.,
commutative diagrams in two or three dimensions). For
example, the 3 x 3 identify matrix might be encoded as:
Matrix[ [1,0,0], [0,1,0], [0,0,1] ]
while the Abstract Syntax expression:
Matrix[5, 5, DiagonalRow[1, ThreeDots[], 1],
BelowDiagonalTriangle[FlexZero[]],
AboveDiagonalTriangle[FlexZero[]]]
might encode a 5 x 5 matrix which is to be displayed with a
"1" in the (1,1) position, a "1" in the (5,5) position, three
dots between them on the diagonal, a big fat zero in the lower
triangle indicating the presence of zeros there, and a big fat
zero in the upper triangle indicating zeros.
2. We assume the use of the ASCII character set for Abstract Syntax
expressions. Greek letters, for example, would need to be
encoded with expressions like Greek[alpha], or Alpha[].
Similarly, font encoding is achieved by the use of Abstract
Syntax such as the following for 12pt bold Times Roman:
Font[timesRoman, 12, bold, <expression>] Two SMCs are free to
communicate in a larger character set, or pass font
specifications in other ways, but they should always be able to
Arnon [Page 6]
RFC 1019 September 1987
express themselves in standard Abstract Syntax.
3. COMPs (e.g., Computer Algebra systems), should be able to
communicate in Abstract Syntax. Existing systems should
have translators to/from Abstract Syntax added to them. In
addition, if we can establish a collection of standard names and
argument lists for common functions, and get all COMP's to read
and write them, then any Computer Algebra system will be able to
talk to any other. Some examples of possible standard names and
argument lists for common functions:
Plus[a,b,...]
Minus[a]
Minus[a,b]
Times[a,b,...]
Divide[<numerator>, <denominator>]
Power[<base>, <exponent>]
PartialDerivative[<expr>, <var>]
Integral[<expr>, <var>, <lowerLimit>,<upperLimit>] (limits optional)
Summation[<<summand>, <lowerLimit>, <upperLimit>] (limits optional)
A particular algebra system may read and write nonstandard
Abstract Syntax. For example:
Polynomial[Variables[x, y, z], List[Term[coeff, xExp, yExp, zExp],
...
but, it should be able to translate this to an equivalent standard
representation. For example:
Plus[Times[coeff, Power[x, xExp], ...
4. A DOC must store the Abstract Syntax representations of the
expressions it contains. Thus it's easy for it to pass its
expressions to EDs, COMPs, or DISPs. A DOC is free to store
additional expression representations. For example, a tree of
Boxes, a bitmap, or a TeX description.
5. DISPs will typically have local databases of formatting
information. To actually render the Abstract Syntax, the DISP
checks for display rules in its database. If none are found,
it paints the Abstract Syntax in some standard way. Local
formatting databases can be overridden by formatting rules passed
over the wire, expressed in Abstract Syntax. It is formatting
databases that store knowledge of particular display
environments (for e.g., "typesetting for Journal X").
The paradigm we wish to follow is that of the genetic code: A
mathematical expression is like a particular instance of DNA, and
upon receiving it a DISP consults the appropriate formatting
database to see if it understands it. If not, the DISP just
Arnon [Page 7]
RFC 1019 September 1987
"passed it through unchanged". The expression sent over the wire
may be accompanied by directives or explanatory information,
which again may or may not be meaningful to a particular DISP. In
reality, formatting databases may need to contain Expert
System-level sophistication to be able to produce professional
quality typesetting results, but we believe that useful results
can be achieved even without such sophistication.
6. With the use of the SMC's specified above, it becomes easy to use
any DOC as a logging facility for a session with a COMP. Therefore,
improvements in DOCs (e.g., browsers, level structuring, active
documents, audit trails), will automatically give us better
logging mechanisms for sessions with algebra systems.
7. Note that Abstract Syntax is human-readable. Thus any text
editor can be used as an ED. Of course, in a typical SMS, users
should have no need to look at the Abstract Syntax flowing
through the internal "wires" if they don't care to. Many will
want to interact only with mathematics that has a textbook-like
appearance, and they should be able to do so.
8. Alan Katz's RFC (cited above) distinguishes the form (i.e.,
appearance) of a mathematical expression from its content (i.e.,
meaning, value). We do not agree that such a distinction can be
made. We claim that Abstract Syntax can convey form, meaning,
or both, and that its interpretation is strictly in the eye
of the beholder(s). Meaning is just a handshake between sender
and recipient.
9. Help and status queries, the replies to help and status queries,
and error messages should be read and written by SMC's in
Abstract Syntax.
10. In general, it is permissible for two SMC's to use private
protocols for communication. Our example of a tightly coupled ED
and DISP above is one example. Two instances of a Macsyma COMP
would be another; they might agree to pass Macsyma internal
representations back and forth. To qualify as SMC's, however,
they should be able to translate all such exchanges into
equivalent exchanges in Abstract Syntax.
Arnon [Page 8]
|
