W3C home > Mailing lists > Public > www-math@w3.org > March 2012

Re: Using content-MathML for computation and analysis in Science and Engineering

From: David Carlisle <davidc@nag.co.uk>
Date: Mon, 19 Mar 2012 17:22:39 +0000
Message-ID: <4F676B5F.3010504@nag.co.uk>
To: www-math@w3.org
On 19/03/2012 08:31, Peter Murray-Rust wrote:
> I have now made progress on my MathCML engine (combined mathematics and
> chemistry). I have been much encouraged by this list and hope I may
> continue to ask questions - any progress I make is updated at
> https://www.bitbucket.org/petermr/mathml.
> One of my uses is to chain simple statements sequentially as in a
> computer program, such as
> x=1
> y=2
> r=x+y
> x=9
> and turn it into:
> <math> // I shall omit namespaces for brevity
> <apply><eq/><ci>x</ci><cn>1</cn></apply>
> <apply><eq/><ci>y</ci><cn>2</cn></apply>
> <apply><eq/><ci>r</ci><apply><plus/><ci>x</ci><ci>y</ci></apply></apply>
> <apply><eq/><ci>x</ci><cn>9</cn></apply>
> </math>
> Can I check that this is (a) valid MathML and (b)
> stylistically/semantically acceptable MathML?

(a) Looks valid to me,
on (b) a couple of mild suggestions that may reduce confusion if that 
were to escape into the wild out of a controlled world where you can 
assert the desired implementation.

MathML allows multiple top level terms but doesn't assign any meaning to 
that, so it might be easier to give meaning (and future flexibility) if 
you had a top level container, could be as simple as
or you could have a custom container
or you could keep it as it is.

2) I think most systems will have a default interpretation of <eq/> as 
an equality test rather than an imperative assignment, and so interpret 
the above as an insoluble set of equations. Probably I'd use something 
like <csymbol>define</csymbol> rather than <eq/>.

> My understanding of the discussion so far is that the "x" in line 1 may
> or may not be the "same as" the "x" in line 3; that MathML is silent on
> this. If so it is legitimate for me to assume it is. It is also
> legitimate for me to assume it carries the value 1 to line 3 and that
> "r" could be evaluated as 3. (It is aso legitimate for others to assert
> that they don't accept these semantics). There is also no universal
> agreed terminology that I can use to enforce my interpretation. That I
> have to use a content dictionary (cd) to make that assertion and that
> (probably) I have to do this in human language

yes, I think I agree with that.

> If this is agreed then I shall continue on this basis. What are the
> potential dangers other than other MATHML users misunderstanding what I
> am doing?

none really. Well all the usual ones such as if your interpretation of
the standard symbols is sufficiently far from someone else's it makes it 
a bit harder to share expressions with that other system, but perhaps 
that doesn't really make sense in this context..
> More generally my engine will wish to manage objects other than pure
> maths objects (e.g. molecules). Can I assume that as long as I simply
> expose the symbols and not the detailed structure MathML will not care.
> For example:
> <apply>
>      <sum/>
>      <bvar>
>           <ci> bond </ci>
>      </bvar>
>      <condition>
>           <apply>
>                <in/>
>                <ci> bond </ci>
>                <ci type="set"> bondSet </ci>
>           </apply>
>      </condition>
>      <apply>
>           <ci type="fn"> bondLength </ci>
>           <ci> bond </ci>
>      </apply>
> </apply>

> will apply the function "bondLength" to a set "bondSet" (which happens
> to be a set of bonds)

For symbols with defined semantics as opposed to free variables in the 
particular expression it's better to use csymbol rather than ci so
> If so, are they stylistic and semantic conventions I should be aware of?


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 Monday, 19 March 2012 17:23:14 UTC

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