[Om3] Skype F2F for calculus3 and condition element in OpenMath

[David Carlisle]

> (which is STS-incorrect), and should have
>         <OMBIND>
>           <OMS cd="fns1" name="lambda"/>

I think the example at 
http://www.openmath.org/cd/calculus1.xhtml#diff
is OK isn't it?

Although the plain text version is rather loose and writes
  derivative(x + 1.0) = 1.0
the OM is OK but applies the dual fix to the one you suggested, applying
the lhs to (an arbitrary) variable rather than lambda abstracting the rhs.

the OM encodes

diff(lambda x. (x+1)) applied to y = 1

rather than

diff(lambda x. (x+1)) = lambda y. 1

> > (D(lambda x. x^2))(x)
> >
> Of course, in OM, (D(lambda x. x^2)) is the same as (D(lambda y. y^2)),
> which again might surprise people.

hence (just to re-iterate the point) the final application to the free
variable x in my example you quote, to remove the lambda abstraction and
make it an expression in the free variable x.

I think that for diff, if we want an expression based version rather
than the current functional diff in calculus 1, it needs to be used with
apply rather than bind and take two arguments, an expression and a
variable

diffexp(f(x),x) being the derivative of f(x) wrt x, however requiring the
syntactic constraint that the second argument is an OMV/ci is rather
against the usual OM style and I think it may be better just to keep the
current position where you have to write

apply(diff(lambda x. f(x)),x)

to get the same effect, and keep the mapping between that and the
expression based form in the pragmatic/strict mathml mapping.

partialdiff is more of a problem, I think we need to have a version that
takes a list of degrees, and a total degree, so OM can support (as
mathml can) symbolic dgrees d^k/d^md^n f(x,y) The OM calculus1 version
taking a possibly repeated list of slots is a pain to work with.

On integrals, Michael's note said OMC wasnt popular but personally I was
warming to it, certainly adding it to Openmath would make the
correspondence with MathML more transparent, even if in many cases it is
strictly redundant and can be replaced by suitable combinations of such
that and similar operators.

Not sure what is best to do about the observation that saying \int_a^b
is the same as \int_{[a,b]} requires a certain amount of good will on the
part of the reader.  Clearly the CD ought to say something a bit more
explict there, but I think that basically it is OK, \int_C always
requires more knowledge about C than just its underlying set, and
(arguably) this is no different.  Certainly on the MathML side, the
notion that all the various "qualifiers" such as lowlimit/uplimit that
could be applied to operators could all be thought of special cases of
the general condition qualifier is deeply engrained and separating out
the semantics now would be difficult I think.

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. 
________________________________________________________________________