[om] different representations for a/b and a*b^(-1)
Richard Fateman
fateman at cs.berkeley.edu
Sat May 18 18:05:29 CEST 2002
David Carlisle wrote:
>>But a/b and a*b^(-1), given the usual algebraic domain are
>>the same.
>>
>
> have the same value but are different terms, just as 4 = 2+2 which was I
> think your previous example. An application can (and some do) do
> arbitrary manipulation on the expression once it is received so might
> store those two in the same form but normally (especially a rendering
> application) you might expect to keep them distinct.
This means that your openmath content is aimed at providing hints
to the rendering application. So you agree with me. so why do you
argue?
This is in
> distinction to yor example of
> a
> -
> b
>
> and a/b which is purely a presentation matter over which openmat, as I
> said before, hives no clue as to teh desired rendering.
Actually I don't see this as so clear cut. You may wish to encode
as part of the message, something significant about the choice of divide
representation. And frankly I think that the choice of a*b^(-1) for
one of these expressions should also be open to the rendering program.
>
>
>
>>If there is a natural encoding in OM then this should come out
>>as foo + foo + foo
>>
>
> I'm sorry but I think you have missed the point of openmath, you
> repeatedly give incorrect descriptions of how openmath (or mathml) works
> and then give valid reasons why a system following that description
> might have problems.
>
> Openmath essentially represents the expression as a tree of
> application/binding terms, as such exp(x)*exp(-y) and exp(x-y)
> would have differnt OM encodings,
OK, so OM is not encoding the semantics, but merely the syntax tree.
Perhaps by reference to some CD, the operators will have some
associated properties. So stop claiming that it represents
math. It is an anotated tree.
You might expect that some OM
> applications might be able to tell these were equal, but not all, in
> particular OM applications mapping to a rendering agent like TeX or
> presentation MathML probably would not identify these two terms.
>
>
>> My conclusion is that the OM content must give essential
>>hints on how to display the expression.
>>
> A conclusion from a false premise.
Actually, I think I am still correct. You are now asserting that
OM content merely conveys a syntax tree, which is exactly the kind
of hint needed. My error was in thinking that the OM content
would represent some kind of canonicalization of content.
>
>
>> I suppose one could
>>put presentation tags on each of the 3 items within the semantics,
>>but would your XSL translator be ready for that?
>>
> As a matter of fact yes you can annotate terms with presentation MathML
> but that doesn't seem particularly relevant here.
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.
>
>
>>Your heuristics might not be the same as mine or those in documents
>>I have been manipulating which use both invisible space and \cdot
>>for multiplication, but with different precedence.
>>
>
> Yes that's exactly my point. The presentation rules are built into the
> stylesheet not into the openmath object as you claimed.
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.
There are lots of varieties of display for this.
cos(a*x)*sin(b*x)
cos(ax).sin(bx)
Cos[a*x]Sin[b*x]
cos ax sin bx
cs ax sn bx
cos a.x * sin b.x
Now you apparently believe that the style sheet would
implement one of these styles and consistently impose it
on the syntax of the expression, and therefore insert the
\cdot or * or invisible_times in the right places. I
don't think so. I think that either the encoding process
must distinguish \cdot from \invisible_times IN THE OM
content description, or the person describing the object
must also provide a presentation. e.g. for TeX,
$ \cos ax~\cdot~\sin bx$ or by the tiresome tools you indicate
below. The style-sheet MIGHT do it (Any CAS display
system does it now), but it will not be right in all
cases.
You may have
> different desired presentation, and your system would show the same
> object in an entirely different notation. That's all as it should be.
Are you familiar with the song "Let's call the whole thing off?"
http://www.theromantic.com/lovesongs/letscallthewholethingoff.htm
in which there are lines like...
you like tomayto and I like tomahto;
The song might be rendered by your presentation program as
you like tomato and I like tomato.
you like a/b and I like a/b ...
missing the point.
>
>
>>I think that your logic and heuristics, regardless of how careful
>>you are, will not be what everyone wants.
>>
>
> As above, we are in agreement here.
>
>
>> Can one say, in the
>>MathML... "in this expression map all multiplications to \cdot for
>>display"? I hope so.
>>
>
>
>
> MathML has two sides, in Presenattion MathML you ask for
> "a binary operator displayed as a cdot" but don't identify it as
> multiplication.
>
> In Content MathML you ask for the multiplication operator (which you
> then apply prefix style, not as an infix operator) You can annotate
> individual operations with presentation mml to force a particular
> display although that's a bit tiresoe or you just use the unadorned
> content markup and take the presentation form that your rendering
> systemuses for that markup. Some systems may allow you to customise the
> default presentation but whether or how they allow such customisation is
> out of scope for the mathml specification. One difference between
> content mathml and OM though is that each content expression does have a
> default presentation, as shown in the spec.
>
> David
>
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
More information about the Om
mailing list