# errata and comments, chapter C (first installment)

From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
Date: Fri, 09 May 2003 16:58:38 +0200
Message-ID: <3EBBC21E.9080803@rrz.uni-koeln.de>
To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>


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

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.

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

(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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:33 UTC