errata and comments, chapter C (second installment)

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 <math> 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 <math> element (because of declare)

C.2.11.13

signature should read 'real constant'

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