[om-a] critique of OpenMath

[Richard Fateman]

Thanks for your comments.  I will try to respond to most of 
them in the next draft (real soon now) to be posted.
It should be on 
http://www.cs.berkeley.edu/~fateman/papers/openmathcrit.pdf


Some specific comments though..

> 
> > ``The nth program must have in its phrasebook a way of understanding
> > "the meaning of Y to the program $X_1, X_2, \dots, X_{n-1}$ if it is
> > to communicate effectively.  Thus the $n^2$ translations are still
> > necessary.''
> 
> This is not true.  Each program must understand the meaning of Y in
> OpenMath which is not always trivial (see Davenport et al's paper discussing
> branch cuts).  Thus there are n translations required.

For some concepts there may be only one translation. For integers I hope
that there will be general agreement.

I don't think anyone else will be able to describe adequately what
is meant by a Mathematica floating point number except to say that
it is a number with inputformat ......  and it comes from Mathematica.
In some other systems it is kind of like an interval.  It is not
enough to point out that Mathematica's ArcTan(x,y) function is to
most other systems atan2(y,x).  It has different semantics as to
what to do about special values, numerical evaluation etc.  So it
is not a common meaning shared by anyone else, in reality.
Certainly Maple's understanding of sin(x) is not the same as (say)
NAG's numerical version.

>....

> 
> Of course, for any particular field one just needs to specify the syntax,
> and whether you use TeX style \ {} or XML style <> makes no difference.
> However if you wish to use existing TeX macros then you have to accept
> that you are imposing your own interpretation of their semantics on them,

Existing TeX macros presumable have no mathematical semantics at all, just
positional/ presentation implications.  There is, so far as I know, no
distinction between a*(b+c)  and   a(b+c)   where this latter form is
an application of a function named "a" to the value "b+c".



> and cannot necessarily treat the same macros from an independent source in
> the same way.  There are also always tradeoffs between using a system that
> aims to be general and extensible (OpenMath) with using a system tailored
> for one particular use. 

In fact Dan Zwillinger, in re-typesetting Gradshteyn & Rhyzik encoded stuff like
zfunction(\sin, x).  Two sets of macros would allow either translation
to TeX or to some computer algebra system  (to the extent possible).

(he prefaced each macro with "z" to try to avoid name conflicts)


>(You give two examples, one of some TeX macros and
> one of a lisp encoding).
> 
> >  See for example Norbert Kajler,
> > Neil Soiffer: ``A Survey of User Interfaces for Computer Algebra
> > Systems''. J.Symb. Comp. 25(2): 127-159 (1998).
> 
> > The SIGSAM article by David Carlisle on OpenMath, MathML, and XSL
> > simply cloaks the easy part of the problem in obscurity
> 
> Glad you liked it:-)
> 
> > ...
> > The simplicity of this is obscured
> > by the demand that instead of writing a program (once) that returns a
> > displayable object, we should write, and debug, a collection of formal
> > XSL that describes the program that displays the object.  In the
> > process of making this indirection, the real difficulties are
> > forgotten.
> 
> No, not forgotten, just moved. You _could_ write a one off program
> to display OpenMath (and some have done that) there are of course some
> advantages to that approach.  We discuss displaying OpenMath by
> transforming to MathML partly to give a comparison of the languages but
> also because by converting to MathML you get OpenMath displayed in
> whatever MathML renderers you have available  (currently there are
> systems going from MathML to pdf, native rendering in
> Mozilla, in Java applet windows, in the Amaya browser, etc). It is a lot
> less effort to write a transform to MathML than it is to try to write
> native OpenMath display code in each of these contexts.  Moreover if
> you wish to customise your display (since e.g. not every mathematician in
> the world uses Anglo-Saxon notation) you need only do it once.
> 
> > It ignores (for example) the interesting problem of
> > breaking expressions over several lines (at all, much less
> > efficiently),
> 
> Yes, I believe that it it is the job of the MathML renderer to line
> break the given MathML (which many don't do so well at present,
> although Mathematica is not bad, which is hardly surprising given Neil's
> longstanding interest in this, as you point out).

Actually, without hints from the source, it is hard to make breaks except
in situations you are quite familiar with.  We may have some reasonable
understanding of how to break  a+b+c+.......+z,  but how do you
break a very long divide bar, or a very long exponent, or some crazy other
thing.  Say a commutative diagram, for arguments' sake.  I think the
MathML renderer can't possibly do all that by itself.
> 
> But take a typical journal accepting author produced TeX files: a
> reasonable proportion of them are handled by printing the files to paper
> shipping them off to some other country with cheaper labour costs, and
> getting the entire document rekeyed. TeX allows authors a lot of
> control, but this often makes the files unusable for any purpose other
> than printing on the author's system. In particular over clever macros
> that break when a journal tries to typeset the document to a different
> page size and with a different font set.  Rekeying from printed output
> isn't our ideal of electronic document processing.

I think that this practice is regrettable too.


 snip

> 
> We have no evidence that any "processes" are holding things up.
> Maybe development isn't as fast as you would wish, but unless you have
> evidence that there is a whole slew of ideas that are being "hidden"
> waiting for "approval" by the Society then we don't understand this
> comment at all.

I guess my reading of the "Procedure for CD Adoption" page led me
to believe that anyone with an idea for a CD would be allowed to
stumble indefinitely for approval, but at least 6 weeks. And the
CD might be rejected.  Such a person could use a CD, but it would
not be official.

I'm not sure about things being hidden, but there are links to

http://www-sop.inria.fr/safir/OpenMath/
which turn out to be a non-existent page.
As for approval, it seems that anyone using the software 
written at INRIA for any commercial purpose may be subjected
to some unknown fee imposed by the authors.


> 
> > Can OpenMath be saved?  Perhaps.
> 
> A related question is, does the world need a language for encoding
> semantics of Mathematical expressions. If the answer to that is "No", then
> OpenMath can't be saved. 

I personally think that there are many languages existing already, and
the question is do we need another one.   I think the answer is
yes only if the new language is demonstrably able to solve problems that
cannot be solved by (say)
Mathematica's prefix form
Lisp s-expressions
Java RMI
Corba
MathML
TeX


>If the answer to that is "Yes" then perhaps
> OpenMath can provide that, and even if not (predicting whether a
> language is a success isn't really possible) the effort that has gone
> into it won't have been wasted. For example the OpenMath Content
> Dictionary effort is mirrored in appendix C of the MathML spec, and any
> other similar language will need some similar construct and could if it
> chose make use of those files. As they stand they probably need
> improvements even for OpenMath use, but that will happen as and when
> more people start to use them.

This may be true, that openmath will live (if no where else) in
appendix C.

> <snip>
> 
> Getting any kind of structured markup out of the TeX in a typical
> journal submission is hard. Many Journal publishers will tell you that
> getting even print out of the TeX supplied by a typical author is hard:-)

This depends on who is doing the translating, and how consistent the
journal is.  Certainly it is sometimes straightforward.  Sometimes you
may have to ask the author what he/she meant by some snippet of TeX.

Thanks form your comments.

RJF
--
om-announce at openmath.org  -  public announcements concerning OpenMath
Post discussion to om at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-announce-owner at openmath.org for assistance with any problems