[Om] getting started with openMath

[Lars Hellström]

Alberto González Palomo skrev 2012-10-09 10.50:
> ken wrote: (09/10/12 05:16)
>> Hello,
>>
>> I would like a simple introduction to openMath xml objects like <mo> (I
>> assume that stands for “math object” but have not yet been able to
>> verify that), and how they are used. I read the The OpenMath Standard
>> 2.0 pdf document but find it confusing.
>
> Well, <mo> is MathML, not OpenMath.

Meaning it's from a different Application of XML, but they're closely 
coordinated, so standard XML tranformation tools can be used to convert one 
to the other, if one needs to. I find OpenMath to be closer to the abstract 
syntax trees of mathematical expressions, so better suited for actually 
doing mathematics on.

> Let's see if I can help you out.
>
>> [...]
>> I was thinking about using openMath for the input format for a wrapper
>> for a Computer Algebra System that would then be used by a C++
>> application I am writing.
>
> That's an advantage only if you want to be able to swap the CAS
> without modifying your application.

Hmm... A question to both of you: Are you thinking about using OpenMath as a 
sort of command language to the CAS, or are you rather thinking about using 
it as a standard for encoding mathematical objects? The suitability of OM in 
a particular case may well depend on one's position in that spectrum.

An example of the latter situation might be that the C++ application is 
outputting something like (i.e., is about as complicated as) matrices whose 
elements in general are polynomials. If you generate OM output, then your 
course is clear the day you discover that real coefficients in the 
polynomials are insufficient (since you actually need to support complex 
coefficients), conversely want to experiment with rational rather that 
floating-point coefficients, or simply need more variables than you 
originally thought. If instead you generate output in some homegrown format, 
then such changes in your data often requires a rewrite from scratch. CAS 
command languages are probably general enough already, but there is always 
the question of how tightly one prefers to tie one end of a toolchain to the 
other end.

> I wanted to do that some time ago, but it does not work well in
> practice: beyond trivial expressions, the differences among CASs are
> so serious that you end up having to create new OpenMath symbols for
> each CAS, at which point the only benefit left is that you need an XML
> parser instead of one for each of the CASs languages. That's valuable,
> but probably not worth the effort depending on what you want to do.

The above sounds a lot like transcribing CAS commands into OM objects. At 
the other end of the spectrum, one doesn't really care about whether the 
Maple arcsin is equivalent to the Mathematica ArcSin or not -- what you care 
about is the sense of arcsin (or whatever) that is relevant for you! It is 
the responsibility of the next step of the toolchain (which may correspond 
to what the OM standard calls a "phrasebook") to make sure that this gets 
represented correctly also at the next stage of processing.


The above does however also suggest an idea, which should be taken as a 
question to the list at large. Might the following, when one seeks to create 
a phrasebook for something large like a CAS, be considered something like a 
"reasonable practice" (since it obviously wouldn't be a Best Practice): set 
up a "dummy" CD into which one just dumps all symbols that the system 
defines but noone has put in a CD yet; that allows you to at least say 
anything you might need to say, even if the meaning of what you're saying 
strictly speaking is completely undefined. And by "dumps" I mean that when 
you need to refer to identifier barbaz in system foo, you do that by saying e.g.

   <OMS cd="foo-LastResort" name="barbaz"/>

I do /not/ mean that there, to make this a reasonable practice, somewhere 
needs to be a content dictionary definition file which contains a 
CDDefinition of barbaz. Indeed, one could even consider making it so that 
explicit entries are added to such "last resort CD:s" only when the symbol 
has been given a proper definition elsewhere, and that the main point of the 
entry is thus to say something like "symbol permanently moved to:".

But this last part is probably off-topic for the original poster; it's more 
in the realm of ideas for standard amendments.

Lars Hellström