# errata and comments, chapter C (second installment)

From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
Date: Wed, 14 May 2003 19:31:25 +0200
Message-ID: <3EC27D6D.2090802@rrz.uni-koeln.de>
To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>, www-math@w3.org

Hi,

I realize that this is a bit late, but I hope it helps anyway.  It's all
bug fixes or concrete applications of more general comments I made earlier.

-- Andreas

---------------------------------------

First a general remark on appendix C:

-  I don't understand why this chapter uses the type 'algebraic' in
signatures.  It just seems to be another name for 'anything', which
is also used in places, but I must report that I for one was
somewhat confused by the term when I first read this text, because
I have been used to seeing 'algebraic' expressions to stand for
things that have to do with polynomials over the complex rationals
and their roots.

C.2.5.3

- closing parenthesis missing after 'Leibnitz notation'

- what is the total degree used for?  I thought that that is always the
sum of the degrees, and thus easily available.  Unless there are
cases where that is not true, I'd suggest to deprecate it.

C.2.5.4, C.2.5.5

- classification of lowlimit(or uplimit, resp.) should be qualifier.

- lowlimit and uplimit are not restricted to integrals, so rephrase
this

- The signature says these can have more than one child?  Why?  What
is the meaning of these if they do?

- more examples are available with the sum and product operators.

C.2.5.6

- classification of bvar should be qualifier

- mention that bvar is productive, i.e. may be used with user-symbol
operators, for example.

C.2.5.6

- mention that degree is a qualifier  (it is, isn't it?)

C.2.5.9

- empty second example

C.2.5.10

- first paragraph, first sentence:  'both a coordinates *vector* ...'

C.2.5.11

- second example

wrap this example in a [itex] element to illustrate that, a),
XML always comes in single elements, and more importantly b),
that declare is restricted to top level.

C.2.6.1, C.2.6.2

- second example

this is not licensed by the signature, which requires a body.

- instead of a condition, domainofapplication may also be used
(see long rationale in previous message)

(bvar, domainofapplication, anything) -> set
(domainofapplication, function) -> set

e.g. {x^n|x\in N}:  set(bvar(x),dom-of-app(N),apply(pow,x,n))
sin(N) :       set(dom-of-app(N),sin)

C.2.6.4

- union correctly allows zero args, so why not intersect?

C.2.6.7,.8

- like the lt/gt/leq... predicates, subset and its cousin are often
seen as chains   A subset B subset C..., and should thus be n-ary in
their signatures.

C.2.7.1,.2

- first sentence, delete 'a' before 'domains'

- signature should include domainofapplication

- case of zero bvars with domainofapplication requires functional arg

C.2.7.3

- description says 'one or more bvars', signature says zero or more

- neither example is licensed by the rest of the spec. They both
use two normal args instead of condition followed by arg.

C.2.7.4

- this element illustrates the need to sometimes use more than one
type attribute.  In this case, their can be a difference whether
tendsto applies over the reals and from above or whether it applies
over the complex numbers, say.

C.2.8.1,.2,.4--.27

- missing parentheses around LHSs of signatures

C.2.8.4--.27

Description
- add 'full' names in parentheses, as in 'sin (sine)', 'cos (cosine)'

C.2.9

- previous general comments on nary functions apply here in several places

C.2.9.1

- spurious paragraph break

C.2.9.2,.3

- typo in second signature (descrete -> discrete)

C.2.9.3

- signature allows a single scalar arg, description requires at least
two.

C.2.9.7

- classification should be qualifier

C.2.10.1

- the second signature should not restrict the allowable child elements

- general comments on n-ary functions apply here too. In particular,

v:= (f_i)_i=1..n

is very common (especially in numerical maths) and should be
expressible as

declare(v,vector(bvar(i),lowlimit(1),uplimit(n),f(i)))

C.2.10.2

- the second comment from C.2.10.1 applies here mutatis mutandis.
In my comments on chapter 4 I discuss this in more detail.

C.2.10.5

- missing closing parenthesis in second signature

C.2.10.6

description
- 'by selecting one fewer items' - remove 'one'

properties
- second property is incorrect  (matrix requires sequence of
matrixrows, not sequence of scalars)

C.2.11.2

missing opening parenthesis in first property

C.2.11.3

first and third properties are the same

C.2.11.6

first property:  use 'factorof' instead of 'divide'

C.2.11.10,(.11)

first property:  use <false/> instead of <cn...>

second property:  wrap in [itex] element (because of declare)

C.2.11.13

signature should read 'real constant'

Received on Wednesday, 14 May 2003 13:31:29 GMT

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