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

[Paul Libbrecht]

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

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

Why don't you think of OpenMath very close to a Lisp expression 
representation of a parse-tree ? Isn't OpenMath somewhat close to TILU's 
internal expression representations ?

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