[Om3] OpenMath Symbols for Symbolic Computation
Peter Horn
hornp at mathematik.uni-kassel.de
Wed Sep 10 21:16:13 CEST 2008
Hi!
>> (1) There is no reasonable representation for matrices.
I'm sorry if this sounded too rude. I should have said: We didn't find
a representation that fitted our needs.
> we have [...]
Sure, we saw these, but for our needs, a matrix representation that's
syntactically similar to the polyd stuff seems more appropriate.
Please find attached the matrix1.html (ocd removed due to size-
limitation on this list), to clarify, I'll show an example:
<OMOBJ>
<OMA>
<OMS name="matrix" cd="matrix1" />
<OMA>
<OMS name="matrix_domain" cd="matrix1" />
<OMA><OMS name="entry_domain" cd="matrix1" />
<OMS name="Z" cd="ringname1" />
</OMA>
<OMA><OMS name="row_dimension" cd="matrix1" /><OMI>3</OMI></OMA>
<OMA><OMS name="column_dimension" cd="matrix1" /><OMI>3</OMI></
OMA>
</OMA>
<OMA>
<OMS cd="matrix1" name="dense" />
<OMI>1</OMI><OMI>2</OMI><OMI>3</OMI>
<OMI>4</OMI><OMI>5</OMI><OMI>6</OMI>
<OMI>7</OMI><OMI>8</OMI><OMI>9</OMI>
</OMA>
</OMA>
</OMOBJ>
The main point is that we need to handle computationally (!) relevant
objects which tend to be EXTREMELY large. If I decide to make an RPC
to a different CAS for some question, the problem obviously needs a
size above a certain threshold. And to allow efficient reconstruction
of the corresponding object, an a priori knowledge of the expected
datatypes is required.
>> (2) arith1.sum, calcucus1.diff etc. all take a function as a
>> parameter.
>> There are several quirks with this:
>> * First, there ARE no functions in OM. From the examples I found
>> that this is referring to fns1.lambda-expressions.
>
> It doesn't have to be a lambda expression, some terms naturally have
> function type already, so you can apply diff to transc1.sin for
> example
> you don't have to construct lambda x. sin(x).
Sure, but again -- I'm referring to objects actually occurring in
practical problems, they are rather of the kind sin(3*x+a)*cos(b*x+c)/
exp(x^2+x+a) where a,b,c are free parameters.
> However it is true that this is a pain in other contexts such as
> aligning with MathML diff and int (which take expressions) and
> probably
> we'll need to support both expression based and function based
> versions
> of these.
That would be lovely!
>> (3) prog1 doesn't really make me happy:
>
> yes it's marked "experimental" for a reason. It covered a very
> simplistic algorithmic language enough for its original use case, but
> most likely anyone needing to enkode algorithms will need to extend
> this.
OK. So we'll discuss this and try to find out our actual needs.
>> (4) There are tons of stuff missing
> That is of cause always going to be the case, the core cds can only
> ever
> be a start, and people working in specific areas will need to add
> more,
> however specific suggestions for new CDs and/or new symbols always
> welcome...
Jip, I thought so. We'll go ahead finding out about our actual needs.
Luckily Dan Roozemond from TU Eindhoven is in the Projects and does a
great job helping us (not only) with OM. Nevertheless, I thought it
might be reasonable to call your attention to our needs during the
developement of OM3.
>> I don't want to gripe
> Not at all, it's good to see interest in updating and extending this
> set.
Fine. :)
Best regards, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openmath.org/pipermail/om3/attachments/20080910/769ca0a7/attachment-0001.html
-------------- next part --------------
More information about the Om3
mailing list