[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