From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>

Date: Wed, 10 Sep 2003 13:04:03 +0200

Message-ID: <3F5F0523.6030704@rrz.uni-koeln.de>

To: "www-math@w3.org" <www-math@w3.org>

Date: Wed, 10 Sep 2003 13:04:03 +0200

Message-ID: <3F5F0523.6030704@rrz.uni-koeln.de>

To: "www-math@w3.org" <www-math@w3.org>

Hi, here are my comments on the extensive changes proposed for Chapter 4, which largely appear to address issues that I had raised during the final-call period. Since the changes were quite extensive, I have many comments, mostly editorial. However, one major point that I have been raising for a long time now, namely the ambiguity between uses of interval as a constructor or as a qualifier, was supposed to have been addressed in this edition in a way that I had approved on this list, but I cannot find the text that had been posted here anywhere in the changes to chapter 4. This problem is therefore still open. -- Andreas ======================================================================= >4.2.1.7 The lambda construct >"This is followed by an optional |domainofapplication| qualifier" For reasons of consistency, I would like this to refer to text that declares all the different ways that a domain of application can be specified in MathML according to the clarifications made in this update. An easy way editorially to clarify the meaning of the above phrase is to link from the word domainofapplication to the place where the semantic equivalence of the several ways of specifying domains of application are described, e.g. (quoting another place in the spec): "Qualifications defined by a |domainofapplication| element can be abbreviated in several ways as described in Section 4.2.3 Functions, Operators and Qualifiers <#contm.funopqual>." > 4.2.1.8 The use of qualifier elements Somewhere in this section, the resolution to the interval ambiguity that you posted on this list earlier should be included. As it is, the ambiguity is not really addressed properly yet anywhere in this chapter. >"by restricting the values of the |bvar| element" This is a bit tricky. At first, I thought that this should read bvar "qualifier" instead of "element," but in fact, neither really fits. Neither bvar elements nor qualifiers have "values", really. What is actually restricted here is the range of possible values of the (mathematical) variable which is specified through the use of a bvar qualifier. > "...|condition| element can be used to place restrictions directly on the on a bound variable..." Typo ("on the on a"). >"This general construction gives natural lifted version of many n-ary operators" There is a minor grammatical error in this sentence; it should read either "a natural lifted version" or "natural lifted versions". >"many n-ary operators, such as..." Is this list meant to be exhaustive with respect to the predefined MathML operators? If yes, compose and the n-ary relations equal etc. are missing. You may also want to produce a similar list (lambda, set, list, vector, matrix...) of constructors that take these qualifiers, after the set example. >"The meaning of constructions of the second form is that the function in the last child is applied to all the values of the set in the |domainofapplication| qualifier." This is not actually correct, since it misses the fact that the n-ary operator needs to be applied, too, in order to get the correct meaning. How about something like this: "The meaning of expressions of the second form is that the operator is applied to the all the values obtained by applying the function in the last child to the elements of the domain of application specified in the qualifiers." >4.2.2.2 Constructors For the updated portions of text describing the use of these constructors (set, list, matrix...) with bvars and domains of application, it would be nice to have examples of these newly clarified uses for implementors to test their products on. >lambda The subsection on the lambda constructor is no longer correct since it misses the possible use of domainofapplication or its abbreviations described earlier in the spec. A possible solution here is to describe the use of lambda more vaguely rather than more precisely, so that dom-of-apps would be allowed by the vaguer description without being mentioned explicitly. > 4.2.3.1 Predefined functions and operators >"The number of child elements in the |apply| is defined by the element in the first (i.e. operator) position..." This has been softened for the n-ary operators, but I thought I had pointed out that it also needs to be softened with respect to the effect of currying, which essentially allows one to drop arguments from the right, producing implicit functions in the dropped argument. E.g. binary functions can have a single argument, in which case they denote a unary function in the dropped (second) argument. (This was one of the points of my question whether or not MathML really wants to define currying or not, which has been adressed elsewhere in the text but not here.) ((After re-reading this, and going through the entire chapter 4, it now seems to me that MathML no longer supports currying at all, as the one place where this feature appeared has been deprecated. If this is correct, the above comment becomes moot, of course. Removing support for currying is probably not a bad idea, given the problems I found in OpenMath in that area.)) >4.2.3.2 Operators taking Qualifiers I noticed that you changed the list of operators taking qualifiers, but I don't understand why this list does not include all those mentioned in the (slightly incomplete) one in 4.2.1.8 mentioned above. (Also, add commas between the newly added elements). >"...except that when they are used as operators, certain qualifier elements are also permitted to be in the enclosing |apply|" This is confusing, since qualifier elements are always "permitted" according to other parts of the spec (which makes sense since predefined elements may be assigned a different semantics via a definitionURL declaration or a semantics element). >"The most general qualifier is the |domainofapplication|. " Slightly confusing -- it's really only the most general of those qualifiers that denote restrictions on the domain of application of the surrounding constructor (condition, interval, lowlimit...), but not the most general qualifier of all (which would include bvar and others...). >"danger of confusing the role one of the short forms" ... role *of* one of... >"Note that the order of bound variables of the integral must correspond to that used by the |set| constructor in the |domainofapplication|." I don't think that that is correct, nor necessary. Their order has to correspond to the order of the entries in the list constructor within that set, not the order in which the bvar elements appear in the embedded set. The following example (which identifies arguments only by their order within a cartesian product) should also be allowed as the body of the domainofapplication qualifier in the example the above text refers to: <apply> <cartesianproduct/> <interval><ci>0</ci><ci>1</ci></interval> <interval><ci>0</ci><ci>1</ci></interval> </apply> This corresponds to a venerable tradition of mathematical notation. >"By using the deprecated |fn| element, it was possible to associate a qualifier schema with a function..." This seems to imply that currying is now deprecated along with the fn element. Is that really intended? As I pointed out earlier, I would have expected you to amend this example to the following otherwise (simply dropping the fn): <apply> <int/> <interval><cn>0</cn><cn>1</cn></interval> </apply> Note that I'm not criticizing -- I realize very much that introducing currying semantics into MathML is dangerous, given the problems I discovered in a related area in OpenMath. I'd just like to make certain that deprecation of currying was the intended result here. >"The meaning and usage of qualifier schemata varies from function to function." You may want to qualify this strong statement a bit by pointing out that the bvar and domain-of-application type of qualifiers are used with a consistent semantics across the MathML operators and constructors, and are meant to be used just as consistently with user-defined symbols or with any other constructs. (That way, OpenMath would be justified in mapping bvar to an OMBinding element across the board, for example). I think you simply missed this implication of my previous comments on generalizing the use of these qualifiers. >forall, exists You missed generalizing the condition to a general domain-of-application here. This also misses the fairly common use of a quantifier with a functional argument -- (\forall \lambda x. P(x)) and (\forall_R \lambda x. x<1) are examples. Both of these I mentioned in previous discussions. >4.2.4 Relations >"The number of child elements in the |apply| is defined by the element in the first (i.e. relation) position." This should refer back to, or repeat, the discussion of arity and its complications for functions. (My earlier comments had pointed out that they referred to both.) >4.2.5.1 Examples The first example doesn't have an argument. In other places in the spec, this was interpreted as currying, which would not give the interpretation that is specified in the accompanying text. I suggest deprecating this example. (I made a similar comment about another currying example of the MathML spec earlier.) I would also suggest using domainofapplication instead of condition somewhere in these examples (e.g. where it says "\in \C"). > 4.4.1.1.3 Examples / 4.4.1.1.4 Default Rendering The type=constant example (tau) and its rendering (pi) don't match. > 4.4.1.2.3 Examples / 4.4.1.2.4 Default Rendering The final example (x_a) and its rendering (x_i) don't match. >4.4.2.1.1 Discussion >"then it is treated as if it were the content of an |fn| element." Rephrase as in 4.4.2.8.1 where another problem like this was fixed. >"Some operators such as user defined functions defined using the |declare| or |csymbol| elements, |diff| and |int| make use of "named" arguments." I discussed this one at length. It still lacks mention of those "other constructs" mentioned earlier in the spec which allow those "named arguments"; in fact, it should say that qualifiers are allowed in an apply regardless of its first child. I believe I gave examples of quantifiers constructed using a lambda expression to show that the range of allowable operators that go with qualifiers extends beyond symbols. >4.4.2.4.1 Discussion >"When used in the body of an |apply| element it serves as a shorthand notation for a |domainofapplication|." This would mean that the example <apply> <plus/> <interval>...</interval> <interval>...</interval> </apply> would not denote addition of intervals (as I believe we agreed it should). I therefore suggest qualifying this sentence with "sometimes" or "may", and referring to the part of the spec that explicitly resolves the interval ambiguity. ((Come to think of it, I didn't see this ambiguity resolved yet in the way that you posted on this list. The section on operators taking qualifiers doesn't address the ambiguity at all. This problem is therefore still open!!)) >4.4.2.7.3 Default Rendering The first default rendering is incorrect, as the example does not specifically name the set of real numbers. >4.4.2.8.1 Discussion This doesn't mention that the declare element is only allowed at the top level. This problem has been fixed in other places of the spec, but this one was apparently missed. >"implied by the use of the |semantics| element. without having to write" Spurious period in the middle of the sentence. >"XML space normalization" Please provide a normative reference for this concept. I can't find any definition. >4.4.2.9.1 Discussion >"The bound variables can be restricted by an optional |domainofapplication| qualifier." I thought the abbreviations would also be allowed here. >"If a |lambda| construct does not contain bound variables, then the arity of the constructed function is unchanged, and the |lambda| construct is redundant, unless it also contains a |domainofapplication| construct" Actually, you do need a lambda with no bvar and no domainofapplication to define nullary functions like random(), as I pointed out in my original request to allow lambda with zero bvars. Thus, the interpretation of lambda with no bvars as applying to an argument function should *only* be used when a domainofapplication is present. This distinction would be more consistent, I believe, and it works better within the framework that I had discussed in my original posts on this topic, too. >4.4.2.9.3 Default Rendering Is there really supposed to be a closing parenthesis in the default rendering of "sine restricted to I"? >4.4.3.4.1 Discussion >"As n-ary operators, these operands may also be generated by allowing a function or expression to vary over a domain of application" ... its operands... (as in the gcd section; you just missed this one) 4.4.3.12 And (and) 4.4.3.13 Or (|or|) 4.4.3.14 Exclusive Or (|xor|) These are all n-ary operators. Their explanations should include phrases like the one in the previous comment, either along the lines of the one for gcd, say, or along the lines for plus (e.g. pointing out that the lifted version of "or" is "exists"). 4.4.3.17 Universal quantifier (|forall|) > "It must be used in conjunction with one or more bound variables" To be consistent with lambda, sum, int, this should allow the functional interpretation in case of zero bound variables, as I have pointed out before. >"an optional |condition| element" This should have been generalized to the domainofapplication. >4.4.3.18 Existential quantifier (|exists|) You forgot to fix "exists" along the same line as "forall". >4.4.4.1 Equals (|eq|), 4.4.4.3 Greater than (|gt|), 4.4.4.4 Less Than (|lt|), 4.4.4.5 Greater Than or Equal (|geq|), 4.4.4.6 Less Than or Equal (|leq)|, Equivalent (|equivalent|) >"The |...| element is an /n-ary relation"/ ...and therefore may be used with qualifiers. (You missed these cases, which should be treated along the lines of gcd). >4.4.5.1.2 Examples >"An indefinite integral is represented by applying the |int| operator to a function without bound variables and qualifies as in..." This sounds like the functional form is now the *only* way to represent indefinite integration. I don't think that that was intended, and therefore recommend continuing the above sentence with " ... or by using the int operator with a bvar qualifier indicating the integration variable...", adding a second example illustrating this case. You may also want to include an example of definite integration in the functional form as an added illustration that the distinction between the functional form of int and its form using bvar is independent of the distinction between definite and indefinite integration; e.g. <apply> <int/> <domainofapplication> <ci type="set">D</ci> </domainofapplication> <ci type="function">f</ci> </apply> >4.4.5.6 Bound variable (|bvar|) I'm missing mention of the fact that bvar can even be used when the first child of an apply is a compound expression. >"...XML space normalization." Again, please link to a normative reference for this term. I couldn't find one. >"It can be necessary to associate additional information with a bound variable or one or more instances of it..." Mention also that an associated domainofapplication or one of its abbreviations can serve to add certain kinds of information to a bvar. >4.4.6.13 Cartesian product (|cartesianproduct|) >"The |cartesianproduct| element is a /n-ary set operator..." ... and can therefore take qualifiers... 4.4.7.1 Sum (|sum|) >"The most general form of a sum specifies the terms of the sum by using a |domainofapplication| element." Not true: the terms of the sum are specified by the argument element of the sum, not the domain of application (otherwise, a sum would almost always return an integer.) I suggest rephrasing this. 4.4.7.2 Product (|product|) The way this is described, replacing sum by product in the final example for sum would not be allowed. Perhaps one should just apply the same changes as were made for sum in this paragraph, too, or refer back to sum and state that product works just like sum etc. 4.4.9.1 Mean (|mea|n), 4.4.9.2 Standard Deviation (|sdev|)... (variance,median,mode) |>"mean|,sdev,variance,median,mode, is an /n-ary operator" ... and therefore can take certain qualifiers... (also, this paragraph accidentally slipped down into the examples section) 4.4.10.1 Vector (|vector|), 4.4.10.2 Matrix (|matrix|) I believe you stated that you wanted to allow vectors and matrices to be constructed with bvars and domains of applications, like lists and sets. This is missing here.Received on Wednesday, 10 September 2003 07:05:41 UTC

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