# errata and comments, chapters 2 and 4

From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
Date: Thu, 08 May 2003 16:42:21 +0200
Message-ID: <3EBA6CCD.10306@rrz.uni-koeln.de>
To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>


Hi,

I've finally had some time to some systematic proof reading. Here's a
preliminary result.

-- Andreas

==========

2.1.3, third paragraph, starts

> A number of functions and operations require one or more quantifiers
> to be well-defined.

It should be 'qualifier', not 'quantifier'.

2.1.4, second paragraph

> and should not require additional arguments or quantifiers to be fully
> specified.

Again, this should probably be 'qualifier', not 'quantifier'.

2.4.5, third paragraph.

> The |id| is also used in this context.

> The id attribute is also used in this context.

4.2.1, list of categories

Move the last category listed (symbols and constants) to the first
position in the list. Usually, lists like this are sorted from simplest
to most complex concepts.

4.2.1.1, first paragraph

> Numbers and symbols are marked by the /token/ elements |cn| and |ci|.

> More elaborate constructs such as sets, vectors and matrices are also
> marked using elements

4.2.1.3 (whole paragraph)

Mention the extra complication of qualifiers and declarations that
change the basic pattern of <apply> op a b ... </apply>.  This has
become necessary since qualifiers are no longer tied to specific values
of 'op' but available for use with user-defined operators, for example.

4.2.1.7 second paragraph

> This is typically an |apply|, but can also be any container element.

It may in principle also be an empty element denoting a constant. (This
applies to 4.2.2.2 lambda as well)

4.2.1.7

Note that the lambda construct can be used with zero bvar elements to
construct a 0-ary function (like random()).  The way I read it, this
paragraph allows this to happen (n=0), but implementers may miss this
special case if it is not made explicit. (This applies to 4.2.2.2 lambda
as well)

4.2.1.8

This currently mentions the use of qualifiers only with predefined
MathML operators.  It should also mention that it is possible to use
qualifiers in any and all apply elements, including those that have
csymbols or ci's or even compound first elements. The set example should
mention that there are other similar cases where bvar qualifiers may be
used (if there are any, that is -- matrix should be one such case, in my
mind, as in A = matrix(a_ij) binding variables i and j).

4.2.2.2 matrix

matrix and/or matrix-row should allow the use of bvars and condition or
domainofapplication qualifiers to specify common notions like matrix A
:= (a_ij)_i=1..n,j=1..m:
<matrix>
<bvar> ... i ... </bvar>
<domainofapplication>
<interval> ...0... ...n... </interval>
</domainofapplication>
<matrixrow>
<bvar>...j...</bvar>
<condition>
...0<j<m+1...
</condition>
<apply> ...a... ...i... ...j... </apply>
</matrixrow>
</matrix>

This applies to vectors, too.

4.2.2.3

mention again that declare is only allowed at the top-level.

4.2.3.1, third paragraph (arities list)

There appear to be exceptions to this rule.

- The spec contains an example where a missing argument is interpreted
as a curried expression, that is the apply missing the argument is
interpreted as standing for a function in that missing argument.

- binary and n-ary functions often induce an easy generalization to
variable-binding operators, e.g. plus -> sum, times -> product, and ->
forall, or -> exists.  In these cases, the operators would be called
with a single argument only (despite being binary, for example), and
with a bvar and a condition qualifier.

4.2.3.1, fourth paragraph "The one exception..."

mention again that declare is only allowed at the top-level (I know that
I used to mis-interpret this sentence to mean that a declare can be
inserted at any level of nesting).

4.2.3.2

I notice that domainofapplication is listed as a qualifier here. Good.
Make sure you mention that in 4.4.2.15.

The second example uses <fn>.  This is deprecated and should not be used
in an example that does not serve as a counter-example.

As mentioned earlier, I propose to deprecate the use of interval as a
qualifier. This would cause several changes in this section.

int; sum and product:

> When used with |int|, each qualifier schema is expected to contain a
> single child schema; otherwise an error is generated.

This is only true if no interval qualifier schema is allowed (which I
advocate).  Intervals tend to have two children.

diff:

The example uses fn, which is deprecated.

partialdiff:

Why is the optional degree qualifier available for partialdiff but not
diff? That seems inconsistent to me.

forall, exists:

I have argued elsewhere that it is not necessary to require at least one
bvar qualifier to go with these.

4.2.4, third paragraph

> It is an error to enclose a relation in an element other than |apply|
> or |reln|.
>
Not true. Here is a counter-example that you'll find in my dissertation:

<set> <lt/> <gt/> <eq/> <neq/> <leq/> <geq/> </set>

I recommend removing this sentence, as I can easily imagine more cases
like this with other containers.

unary/binary/... : the discussion above applies here too.

4.2.5.

mention that conditions can be used with arbitrary "heads" of their
apply, just like bvars.

4.2.5.1, second example

use MathML constant symbols instead of OpenMath csymbols for the sets N
and P.

4.3.2.5 nargs:

add a possible value to specify that the declared operator follows the
model of quantifiers or sum/prod/int/max/min/... 'Binder' is used in
OpenMath, 'quantifier' or 'generalized-quantifier' might be
alternatives, too.

4.4.2.1.1 last paragraph

Mention user-defined symbols in the context of qualifiers, too.

4.4.2.4.1, last sentence

> The |interval| element expects /either/ two child elements that
> evaluate to real numbers /or/ one child element that is a |condition|
> defining the |interval|.
>
the condition qualifier has to be used with bvars according to earlier
parts of the spec.  Thus, we actually have 4 distinct possibilities:

a) interval(a,b)
b) interval(bvar(x),condition(p))
c) interval(lambda(bvar(x),p))
d) interval(p) where p is a unary predicate.

However, I think that b) through d) are covered by the set and
domainofapplication elements already, so that there is little to be
gained from allowing them in addition to a).

4.4.2.7.1.

mention that reln is deprecated.

4.4.2.9.1

it should be possible to use lambda to construct nullary functions (that
is, use lambda with zero or more bvars).  mention also the possible use
of domainofapplication etc.

4.4.2.9.3

shouldn't the default rendering be more like  \lambda x. f  ?

4.4.2.11

shouldn't ident have an optional argument giving the domain it is the
identity function for?  Default rendering of ident(D) would then be   id_D.

4.4.2.15

mention that domainofapplication is a qualifier element.

4.4.2.16

I'm not sure that it is a good idea to disallow degenerate versions of
piecewise that have no piece elements at all.  When this kind of
expression is generated by computer, I can easily imagine cases where
somewhere in the simplification chain for a smooth function description
it might go through just such a form, to be simplified in the next step.
However, one could imagine a case where the knowledge for this extra
simplification step that strips away a piecewise with a single otherwise
child resides in an external application...  Even the completely
degenerate form of an empty piecewise expression could easily come up in
a chain of reasoning that proves that a certain function definition

4.4.3.5

4.4.3.17, 4.4.3.18

again, I have argued elsewhere that requiring a bvar is unnecessary as
there are common examples where one does not appear.

4.4.5.1.1

The domain of integration may actually be specified in more different
ways:  lowlimit/uplimit, interval (which should be deprecated),
domainofapplication, condition (with bvar(s)).

Mention that the bvar element specifies the integration variable.

4.4.5.1.2

If the use of interval as a qualifier is deprecated (as it should), the
second example needs to be changed so that the interval element is
wrapped with a domainofapplication.

4.4.5.2.2

I'm surprised that diff is only for single-variable differentiation.  I
thought that it would also stand for total differentiation in multiple
variables.  In this case, optional degree arguments and the possible
two-argument variant specified in partialdiff should apply here, too.

4.4.5.6.1

mention that bvar can be used with user-defined or even compound "heads".

4.4.5.6.3

the default rendering of the first example should be $\frac{d^2 x^4}{dx^2}$

4.4.5.8/9/10

add default renderings with \nabla, as in the case of the laplacian.

4.4.6.9/10

the default renderings in 4.4.6.9 and .10 need to be swapped.

4.4.6.13

we're clearly missing a cartesianpower element to represent $\R^n$,
n-dimensional real vector space -- although
cartesianproduct(bvar(i),condition(0<i<n),reals) would work, too ;-)

4.4.7.1, .2

we can also use domainofapplication here.  Mention also that a function
argument without a bvar qualifier is possible.

Appendix I.2, last sentence.  There is a grammatical error in this sentence.

Received on Thursday, 8 May 2003 10:42:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:54 GMT