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
_______________________________________________
Om mailing list
[email protected]
http://openmath.org/mailman/listinfo/om
