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

Received on Thursday, 27 April 2000 10:40:00 UTC