> (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. ________________________________________________________________________ _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
