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

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

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