From: David Carlisle <davidc@nag.co.uk>

Date: Wed, 18 Jul 2012 13:00:38 +0100

Message-ID: <5006A566.10600@nag.co.uk>

To: Andrew Miller <ak.miller@auckland.ac.nz>

Cc: www-math@w3.org

Date: Wed, 18 Jul 2012 13:00:38 +0100

Message-ID: <5006A566.10600@nag.co.uk>

To: Andrew Miller <ak.miller@auckland.ac.nz>

Cc: www-math@w3.org

On 26/03/2012 04:34, Andrew Miller wrote: > On 26/03/12 07:57, Andrew Miller wrote: Sorry about the delay.. >> Hi all, >> >> Section 4.6 includes the following text under point 4b: >> >> "Rewrite interval, vectors, matrices, and matrix rows as described in >> Section 4.4.1.1 Interval |<interval>| >> <http://www.w3.org/TR/MathML/chapter4.html#contm.interval>, >> Section 4.4.9.1 Vector |<vector>| >> <http://www.w3.org/TR/MathML/chapter4.html#contm.vector>, >> Section 4.4.9.2 Matrix |<matrix>| >> <http://www.w3.org/TR/MathML/chapter4.html#contm.matrix> and >> Section 4.4.9.3 Matrix row |<matrixrow>| >> <http://www.w3.org/TR/MathML/chapter4.html#contm.matrixrow>". >> >> However, sections 4.4.9.1, 4.4.9.2, and 4.4.9.3 do not describe any >> rules on how to rewrite vector, matrix, and matrixrow elements. >> >> Given that vectors (and matrices, and matrixrows) can have domain >> qualifiers, I presume that there is supposed to be a transformation >> like the one for sets, although it is not clear what OpenMath the >> following is supposed to map into: >> <vector> >> <bvar><ci>x</ci></bvar> >> <domainofapplication><set><cn>1</cn><cn>2</cn><cn>3</cn></set></domainofapplication> >> <apply><plus/> >> <ci>x</ci> >> <cn>1</cn> >> </apply> >> </vector> >> >> The OpenMath linalg7 CD has a list_to_vector symbol, but it is a >> binary function that requires the ring of the vector to be specified >> explicitly. >> > It looks like 4.3.1.2 suggests that the unusual non-strict MathML: > <apply> > <vector/> > <bvar><ci>x</ci></bvar> > <domainofapplication><set><cn>1</cn><cn>2</cn><cn>3</cn></set></domainofapplication> > <apply><plus/> > <ci>x</ci> > <cn>1</cn> > </apply> > </apply> > can be transformed to: > <apply><csymbol cd="fns2">apply_to_list</csymbol> > <csymbol cd="linalg2">vector</csymbol> > <apply><csymbol cd="set1">map</csymbol> > <bind><bvar><ci>x</ci></bvar> > <csymbol cd="fns1">lambda</csymbol> > <apply><csymbol > cd="arith1">plus</csymbol><ci>x</ci><cn>1</cn></apply> > </bind> > <apply><csymbol cd="set1">set</csymbol> > <cn>1</cn><cn>2</cn><cn>3</cn> > </apply> > </apply> > </apply> > > So maybe the rule in 4.3.1.2 should be adjusted so it applies to the > more usual form <vector>...</vector>, and 4.6 updated so that it refers > to the newly added rule (and likewise for matrix and matrixrow). > > Best wishes, > Andrew The above would be a possibility, however an alternative reading was implemented by Robert Miner in his XSLT implementation of that algorithm (currently available from) it gives: $ saxon9 AM1.xml c2s/c2s.xsl <math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <csymbol cd="fns2">predicate_on_list</csymbol> <csymbol cd="linalg2">vector</csymbol> <apply> <csymbol cd="list1">map</csymbol> <bind> <csymbol cd="fns1">lambda</csymbol> <bvar> <ci>x</ci> </bvar> <apply> <csymbol cd="arith1">plus</csymbol> <ci>x</ci> <cn>1</cn> </apply> </bind> <apply> <csymbol cd="set1">set</csymbol> <cn>1</cn> <cn>2</cn> <cn>3</cn> </apply> </apply> </apply> </math> That is, it is applying the general rule at step 6 to use predicate_on_list to encode any remaining qualifiers. Given that this seems to be an edge case I think a less disruptive possibility would be to clarify that 4b just refers to using the tables in those sections to specify the correct CD symbols, but that any qualifiers would remain until step 6. Does this seem reasonable? David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________Received on Wednesday, 18 July 2012 12:01:15 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:45 UTC
*