errata and comments, chapters 2 and 4

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.

should read

 > 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|.

add 'respectively'.

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

'marked up' instead of 'marked'?

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 
leads to an empty domain.

4.4.3.5

add a unary minus example.

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

add a degree example.

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 UTC