[Prev][Next][Index][Thread]
Re: Iterators/Apply-qualifiers in MathML 2.0(content)
> 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 Strotmann
References: