path: root/doc/rfc/rfc1019.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L