errata and comments, chapter C (first installment)

Hi,

here is another set of comments on roughly the first half of Appendix C.

Can I have an extension of the deadline for comments?  I'd like to 
finish this chapter and appendix B next week.  Sorry -- I had more 
comments to make than I had thought beforehand.

Anyway, I hope this helps,

 -- Andreas

============================================

C.1 second paragraph, second sentence

strike 'if'

C.1.1 first paragraph, first sentence

'used' -> 'use'

C.1.1 third paragraph

first word "This" -> 'The';  insert comma after 'standardization effort'

C.1.2

- function (operator), second paragraph, third sentence

insert 'as' after 'used'

- signature, second paragraph, first sentence

 'to type of mathematical object that is constructed.' -> 'to the type 
of the mathematical object it constructs' (for example)

C.2.2.2

replace 'reln' by 'apply' in the formal production rule.  Rationale: the 
application should have used 'apply' instead of 'reln' anyway, so just 
treat it as one semantically.

C.2.2.3

"This constructor has been deprecated":  I've been confused, reading the 
spec, to what extent this is true.  Sometimes the spec seems to say that 
fn has only been deprecated for certain uses rather than fully and 
completely.  Please check all places in the spec that have fn in them to 
check what exactly they say about deprecation, and make sure they all agree.

C.2.2.4

There is a consistency problem here.  

a) This chapter has interval as a constructor only, not as a qualifier. 
Since I recommend removing the use of interval as a qualifier, this is 
fine with me, but consistency with the rest of the spec is important here.

b) Chapter 4 describes how to use interval with a single argument, a 
condition.  Note that I commented on that earlier, with a recommendation 
to strike that extra complication, in which case this paragraph would be 
correct.  As Chapter 4 stands, however, the single-argument condition 
version of an interval is undefined here (if it is kept).

C.2.1.2 vs. C.2.2.5

the first example uses <ci type=function>, but 'function' is not an 
allowable type listed in C2.1.2 nor could it be deduced from rules that 
include constructor element names by reference into the list of allowed 
types for ci (type =lambda might work ;-) .  This is a problem of 
consistency only.  I recommend adding function in C.2.1.2 in order to 
resolve this issue.

C.2.2.7

signature '(apply)' is too restrictive, since constants and symbols 
should be allowed. Also, somewhere in the spec it says you can use sets 
as conditions, not just predicates. In that case, set name symbols would 
be useful in more than just degenerate cases.

C.2.2.9

the formal signature and the rest of this paragraph (correctly!) state 
that there are zero(!) or more occurrences of bvars. Other places in the 
spec (incorrectly!) insist on at least one bvar, including the content 
markup validation grammar. There is an inconsistency here.

> Note that a lambda expression on an arbitrary function applied to a 
> simple argument is equivalent to that arbitrary function.
>
I don't understand the previous sentence.  If you mean to express

  \lambda x. f(x) = f

then the sentence needs to be re-phrased in order to ensure that the 
'simple argument' is the single bound variable of the lambda, because 
the statement is false otherwise.

C.2.2.10

use a small circle Unicode character instead of @ in the description.

C.2.2.13

The property should use Exists as in   Forall(y, Exists(x,y=f(x)), y in 
codomain(x))

C.2.2.14

The property should involve image, not codomain.  Also, you have a 
definitory equivalence and not just an implication here, which you may 
want to express.

How about this extra example:  Forall(f, x in image(f), x in codomain(f)).

C.2.2.15

this should mention that domainofapplication is a qualifier element.

The formal signature is incorrect, as the example shows. Its argument is 
a set, not a function, and its result is the same set (it it can 
properly be seen to have a result, since it really is a qualifier 
changing the meaning of the surrounding apply).

I don't think this belongs into this section. I think it should go 
wherever condition is defined.

C.2.2.16

The formal signature allows zero pieces, but requires at least one 
otherwise.  The former is correct, the latter incorrect (it should be 
zero or one otherwise).  Note also that there are consistency issues 
with respect to Chapter 4 and with suggestions I have made on that chapter.

C.2.2.17

The formal signature is incorrect.  Replace 'algebraic' by 'anything'. 
 Rationale: you can define a piecewise relation, too, though admittedly 
that would be a bit unusual.

C.2.3.1 first paragraph

'positive' -> 'non-negative' (since a may be 0)

C.2.3.4, C.2.3.5

I'm not sure if the 'condition' in the formal signature includes 
domainofapplication elements. If not, this needs to be amended.  Also, 
to be consistent with, say, int, the signature

 (domainofapplication, function) -> anything  

[or perhaps (... -> codomain(function)), to be more specific] should be 
allowed with the meaning of the supremum of the function over the 
specified set.

In the last example, the interval should render as a closed interval.

C.2.3.12

add signature  (anything*) -> anything.  Rationale: there are lots of 
other places where a gcd makes sense, and not all of them have a 
well-defined MathML-type to go with them.

add signature   (bvar,condition,anything) -> anything  which defines the 
gcd of all elements thus described.  [This extra signature should be 
added to all nary function symbols (plus, geq, and, etc.) in MathML 
because the spec allows it and it makes sense.] May also need to add 
signature  (domainofapplication,function) -> anything [again for all 
other nary function symbols, too].

C.2.3.18

If you specify earlier, as I recommend here, that the type of a reln is 
apply, then you can strike the second signature.

If you go with an earlier recommendation of mine, you should allow the 
signature  (domainofapplication,function) -> boolean.

Note that this specification (correctly!) says that there are zero(!) or 
more bvars.  I have noted previously that there are cases in other parts 
of the spec that claim that there needs to be at least one bvar.

C.2.3.19

The description and the signature are incorrect, and should be rewritten 
from scratch based on the (corrected) text for forall (C.2.3.18).

C.2.3.23

For clarity, make the MathML type=real explicit in the ci elements of 
the MathML version of the property.  (actually, the default type of a ci 
element is specified as complex somewhere, isn't it? in that case, this 
change is necessary to make the property come out right.)

C.2.3.24

The property is only correct if the type of x and y is specified as 
real. See C.2.3.23.

C.2.4.2

An n-ary version of neq makes sense too, returning true if none of the 
arguments are equal. this paragraph should be more like the ones for eq, 
lt, gt, leq, and geq then.

C.2.4.7

Why does this use logical instead of boolean???  Also, why can't 
equivalence be used to represent arbitrary equivalence relations over 
arbitrary domains (with signature (anything*)->boolean)?

C.2.5.1

Add signature

(domainofapplication, function) -> anything

which is needed in some examples in this spec (e.g. $\int_D f$).

I also suggest removing the interval signature, based on previous 
comments I have made.

It may also be necessary to add

  (bvar, domainofapplication, algebraic)->algebraic

if domainofapplication is not included in condition.

In addition, the spec says in other places that more than one bvar is 
allowed in most cases, and this should be reflected in the signatures.

C.2.5.2

I remarked in my previous posting that this should perhaps be defined 
more like partialdiff.

C.2.5.3

The examples and properties should use partialdiff, not diff.

The third property is not allowed by the signatures.  Either fix the 
property or the signatures.

Received on Friday, 9 May 2003 10:58:43 UTC