[Om] getting started with openMath

[ken]

Hello, Lars Hellström

I was thinking of using OpenMath as a command language to access the 
CAS, not as a standard for encoding mathematical objects in the CAS. 
Like a explained to Alberto I was think of using openMath to abstract 
the CAS I use from the rest of my application so I could change the CAS. 
It seems like it is turning out to be a lot of work and may not be worth 
it. Are you saying that openMath is better suited for use inside a CAS 
and not for a way to pass things between different applications or 
components?

So I am confused about this arcsin thing. Does not arcsin always output 
the same thing for a given input, so why would anyone ever want to 
define it differently? If I enter arcsin(1) into a calculator I expect 
to always get back pi/2 rad or 90 deg. The unites and whether it is 
exact would need to be defined but they are all equivalent and I should 
be able to get it in any form needed and change between any of them as I 
like depending on the CAS, so that is out side the definition of arcsin.

That brings up another question. Is there any way to specify unites in 
openMath. That becomes a big thing if physics? If I ever get that far (I 
doubt I will) I would like my calculator to be smart enough that it 
would change everything to si units before solving an equation where 
units are specified.

Thanks and have a good day.

Ken


On 10/09/2012 07:02 AM, Lars Hellström wrote:
> 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
>