From: Andreas Strotmann <strotman@nu.cs.fsu.edu>

Date: Thu, 27 Apr 2000 10:39:54 -0400 (EDT)

To: "Je'ro^me Euzenat" <Jerome.Euzenat@inrialpes.fr>

cc: www-math@w3.org

Message-ID: <Pine.GSO.4.10.10004270949590.13428-100000@xi.cs.fsu.edu>

Date: Thu, 27 Apr 2000 10:39:54 -0400 (EDT)

To: "Je'ro^me Euzenat" <Jerome.Euzenat@inrialpes.fr>

cc: www-math@w3.org

Message-ID: <Pine.GSO.4.10.10004270949590.13428-100000@xi.cs.fsu.edu>

> I have one suggestion about the opportunity to qualify apply > in MathML. > > Remark 2: > Meanwhile, there is a need for a general "iterate" primitive > (maybe not the best name). Which iterate any operation on variables, > like in the way apply does it with qualifiers (4.2.3.2). Such an operator > would have the advantage of caring of the iteration in place of the > operator itself. As an example, it is perfectly legitimate to apply > an iteration to: I agree with you that such a thing is needed in MathML, but I think another solution to this problem that I proposed earlier on this list would both be cleaner and more natural to mathematicians. For this purpose I suggested in an earlier message to allow the <bvar> and <condition> qualifiers to appear in any apply. The intention was to have the default semantics of an <apply> <associative-binary-operator/> <bvar>....</bvar> <condition> ... </condition> ... </apply> be what you call the iterator of the construct, similarly to the way many iterators are represented on paper by a "big" version of their binary operator representation. This solution has the following advantages: -- no need to introduce yet another constructor -- realizes all(?) the "iterator" constructs' intention -- easily generalizes to default semantics for, say, unary operators -- easily generalizes to using possibly structured operators -- easily generalizes to using operators that can only be used with <bvar>s (such as new quantifiers) Note also that the <interval>, <uplim>, and <lowlim> qualifiers are special cases of the <condition> qualifier, so that it may not make sense to use the former in a more general setting than strictly necessary. Unfortunately, all four of these qualifiers (with the exception of the <condition> qualifier) have a fundamental problem that I pointed out more than two years ago, which your <iterator> solution fails to solve: the scopes of these qualifiers are *outside* the scope of their corresponding <bvar>, while other arguments of the <apply> (or <iterator>) are *within* its scope (see my message of November 1998 for details). This makes for a very unclean design, and is the reason why OpenMath opted *against* including such qualifiers, requiring instead that operators such as <int> be functions that take functional arguments (plus the set that the argument function ranges over as a second argument; see example below). The <condition> element explicitly is *within* the scope of its <bvar> according to the MathML definition, so its use is much cleaner for a general semantics than the general use of the other qualifiers. Unfortunately, restricting oneself to the <condition> and <bvar> qualifiers makes it impossible to specify, say, int(lambda(x,sin(x)), [0..x]) the way OpenMath defines it (note that int here is a function taking a function and a set as arguments!). But that is probably no problem since it is easy to specify different semantics for an operator with the same name and a different signature ( (set,function) ->... ). BTW: Does MathML 2.0 as it currently stands allow the equivalent of int(f, D) with f and D content identifiers (f a function, D a set) with the semantics of an integral of the function f over the domain D, without introducing a spurious variable x and writing the equivalent of int(f(x) dx, x in D) ? I think I pleaded those two years ago or so that this be allowed in compatibility to OpenMath, but I'm not sure it is any more. Regards, Andreas StrotmannReceived on Thursday, 27 April 2000 10:40:00 UTC

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