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

[Richard Fateman]

Paul Libbrecht wrote:

> Hey, that's getting spicy !
> I'll allow myself a bit of spice if I dare...
> 
> On Samedi, mai 18, 2002, at 06:05 PM, Richard Fateman wrote:
> 
>> Right, because your syntax tree is not content at all.  It is 
>> approximately a description of the appearance.  It distinguishes 
>> between 1/exp(x),
>> exp(-x), e^(-x), 1/e^(x), but for some arbitrary reason CAN'T
>> apparently distinguish between
>> 1/e^x  and
>>    1
>>  -----
>>     x
>>    e
>>
>> I see no reason to forbid  a/b  as  a <mop> divide_solidus </mop> b
>> or some such OM-like notation.  I think solidus is the name for
>> the / character.
> 
> ("some such om notation", looks like you've already such a nonsense, I 
> haven't)
> 
> I'm really amazed by your point and really have the impression you've 
> never ever worked on anything that's close to rendering.


Well, this is not true; in fact I wrote a translator from
Macsyma to TeX.


> 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.


> I do know that exp(-x) and 1/exp(x) are the same >>FUNCTIONS<< because I 
> know math and I can apply (and prove) theorems. 


I know of no circumstance in which they differ.

(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 - .)


> 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.


> 
>> No, that is exactly NOT the point I was making.
>> Consider the expression
>>    cos(a*x)*sin(b*x) as typeset in some books.   It looks like
>>     cos ax . sin bx       where the .  is centered.
>> If there is to be ONE tree describing the syntax of this, sufficient
>> for a display program to render it as expected, the encoding
>> must encode the whole expression including the two varieties of
>> times, which the author apparently thought of as significant.
> 
> 
> Using standard content dictionaries and nothing else, you can, indeed, 
> probably only render this with cos(a.x).sin(b.x) (note however, that 
> rendering engines are become more intelligent every day and that such 
> stylist rules may come in one).



> 
> However you can extend OpenMath with a style hint as you want to go for 
> a rendering, OMDoc does this.
> However, this is also irrelevant for the core OpenMath: these are the 
> same mathematical expressions, whichever way you write it.
> Style hints are absolutely classic, just about everywhere. Even in latex...
> 

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.


> 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.  Calling it "semantic" or
"content" is like calling it "standard".  The words should
not be taken literally, but only informally.

Isn't OpenMath somewhat close to TILU's 
> internal expression representations ?
> 

  I suspect that OM is two orders of magnitude more verbose
and also insufficient without defining operators that
suggest the actual semantics I need.  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. 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.
The latter idea is used for communication
between the macintosh graphing calculator and tilu.
I suspect that another reason not to use
  OM is that it is still not defined completely.

RJF





--
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