[om] different representations for a/b and a*b^(-1)

Paul Libbrecht paul at activemath.org
Sun May 19 13:57:47 CEST 2002


On Samedi, mai 18, 2002, at 09:40 PM, Richard Fateman wrote:
> Well, this is not true; in fact I wrote a translator from
> Macsyma to TeX.

OK, now, what about a rendering engine for a collection of authored 
documents ?

>> The advantage of OpenMath in precisely not distinguishing the big 
>> fraction and the slash is because they have the exact same meaning 
>> (I'm calling this semantic).
> I thought that we disposed of this misconception.  OM does
> not deal with meaning. It deals with syntax trees.  Since it
> deals with syntax trees, I see no problem in having different
> operators for division.

Yes, I agree that the naming "semantic" is just absolutely fuzzy. In a 
sense, everything is a syntax tree, so this is also an absolute 
non-sense...

> (Oddly enough, some computer algebra systems equate exp(x) and e^x  
> which arguably are not the same.  exp(1/2) is a single value, but 
> e^(1/2) = sqrt(e) = two values + and - .)

You're in the right world as you consider this as a mistake.

>> They are however, sorry to say it, >>not the same math expressions<<. 
>> Wether they're the same function is the work of some processes (which 
>> can take infinite amount of time if more complicated).
> I'm not asking for OM to solve undecidable problems. I'm only
> try to get it to say what it does do.  I thought I got that
> clarified.  It is transmitting trees.  Essentially
> what  Lisp's functions   (setf x (read))  and (print x)
> do.

This looks like procedural stream-things... so I'm unclear here...


> I suspect that you have not done what I have done, which is
> look at tables of integrals published in France, USSR, USA, between the 
> years 1837 and the present.  Styles vary.

And don't you think that there were some special annotations between the 
authors and the typists of these big works ? That's what I call style 
hints....

>> Why don't you think of OpenMath very close to a Lisp expression 
>> representation of a parse-tree ?
> I will do so from now on.   A verbose uninterpreted (except by
> occasional informal comments) tree.

Oh, but if you find it too verbose, just pick another syntax. There is a 
lisp syntax for XML and it would probably taste better to you (and it is 
generally the way the very few Lispers that consider XML do it).

> Calling it "semantic" or
> "content" is like calling it "standard".  The words should
> not be taken literally, but only informally.

Now, you're just fighting on naming...
I believe OpenMath does a better job in standardization than TeX does... 
The idea of making it a standard is to promote interoperability which 
we're striving for.

>  I suspect that OM is two orders of magnitude more verbose
> and also insufficient without defining operators that
> suggest the actual semantics I need.

So what's your definition of "semantics". I can't believe your semantics 
want to differentiate the big fraction from the in-line one, or does it ?

> For example, if I find 2 or more answers in my data base I have a 
> construction that says essentially that the user should pick one of 
> them to continue the computation.
> Sure I could write a CD for this, but anyone interested
> in getting answers from Tilu can more easily get the
> results by using lisp's read.

Again, too much lisp for me.
I don't catch the point of the CD for a choice, this looks quite odd 
(but... you're free to add a symbol whenever you want as long as you 
keep it for you, no-one will complain).

> An alternative
> that I have used, and takes about 25 lines of code, is
> to program a simple infix traversal of the tree and print out a 
> character string which is transmitted.

So that's printing a little (linear) string out to represent the 
expression.
The thing is... you just care about a linear string, which makes Tilu's 
output not so rich display (this is kind of ok for only real, integer or 
complex functions). If TILU would ever think about using OpenMath, it 
could take advantage of many available rendering things.

> I suspect that another reason not to use
>  OM is that it is still not defined completely.

Saracasm: do you mean it should cover the whole mathematics ?

Paul

PS: since there is a fair similarity between lisp trees and OpenMath 
trees, I've always been wondering why the beautiful and powerful Lisp 
implementations never came to solve the hard problems of XML. XML 
databases are certainly one good example. And an XSL transformer that 
could achieve the famous "a little change in the source, a little change 
in the output" would also come great.
--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems



More information about the Om mailing list