- From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- Date: Fri, 11 Jul 2003 16:41:04 +0200
- To: Stan Devitt <jsdevitt@stratumtek.com>
- CC: www-math@w3.org
Stan, sorry for responding a bit slowly, but I'm swamped with other work these days. Stan Devitt wrote: > > Andreas, > > Going over your message on chapter 2 and 4 on May 8th, I think we > have now gone through all the issues. I have structured this note as > a summary of the current status and the outcome on each open issue. I > have included a copy of the original note for completeness. Thanks. > Thee small editorial changes have all been made except in some > instances that boil down to editorial style. I only discuss here the > major points that are not marked in our records as confirmed closed. I agree. We already went over the others before. > According to our records, the main items arising from this message > that we have not got confirmation on are: > > 1. proposed deprecation of interval. (our issue# 13-14) > > OUTCOME: We have elected to keep interval as both a qualifier and a > regular object, but have described how to resolve ambiguitie that may > arise. I think I said in a previous message that I was happy with your resolution of this issue. > 2. possible values of the type attribute (our issue# 13-16) > > OUTCOME: We have clarified that the type attribute value is an > arbitrary string and so can be, for example, a space or comma > separated list of other common values. We have added a "function" > attribute value to the list of known types to help avoiding use of the > deprecated fn container name. Good. > 3. partialdiff versus diff structure (our issue# 13-17) > > OUTCOME: We have retained the univariate structure of diff. This > helps to ensure there is no confusion between which notation to use, > and having clarified that qualifiers can be used with user defined > symbols, the functionality and interpretation you are seeking can be > formalized without needing to use diff. This should be flagged as a > candidate for review in the future as some such conventions develop > and stabilize. As I said in my previous post, I agree with your resolution of this issue, both in the sense that it is OK to leave it as-is for the moment, and in the sense that it should be left as a candidate for review later. > 4. 4.2.4 the wording about binary relations. (our issue# > 13-20) > > OUTCOME: This wording has been revised along the lines you suggest. > We have also made it clear that more than one classification may be > possible for an operator. Sounds good. > 5. 4.3.2.5 introduction of a type attribute value to denote > nargs. (our issue# 13-23) > > OUTCOME: Since the type attribute takes arbitrary strings as values > this is already permitted in the present spec. We did not formalize > "nargs" as a possible value as we were wanting to focus more on > mathematical types than on structural types;. More needs to be said > on facilitating types and that will appear in a forthcoming note on > that topic. That's fine. > 6. 4.4.2.11 ident having a "domain". (our issue# 13-30) > > OUTCOME: We did not make any formal change to ident in this regard. > We did however follow your suggestions to clarify the use of lambda, > in particular, that you may associate a domain with a function so that > > <declare> > <ci>IDENT</ci> > <lambda> > <ident/> > <domainofapplication><ci type="set">C</ci></domainofapplication> > </lambda> > </declare> > > creates just such a named function. OK -- but I'm not sure I understand your lambda example above. Shouldn't that be <declare> <ci>IDENT</ci> <lambda> <domainofapplication><ci type="set">C</ci></domainofapplication> <ident/> </lambda> </declare> (aren't qualifiers supposed to precede arguments? The generalized quantifier here is the lambda, which means there is no operator in a lambda.) Also, I believe I was thinking more along the lines of phrasing this particular example as follows (with an explicit bvar), although that doesn't really matter much: <declare> <ci>IDENT</ci> <lambda> <bvar> <ci>x</ci> </bvar> <domainofapplication><ci type="set">C</ci></domainofapplication> <apply><ident/> <ci>x</ci></apply> </lambda> </declare> > 7. 4.4.2.16 degenerate cases for piecewise (our issue# 13-32) > > OUTCOME: We have relaxed these constraints so that the degenerate > cases may now occur. Good. > Once again, confirmation from you that we have addressed these major > points will help us to track these items properly. As far as I remember, this indeed covers all the major points that I raised. I'm looking forward to seeing the outcome of this round of revisions to MathML 2.0. Going through my original message below, I believe there is only a single minor editorial point that I don't recall having seen an explicit resolution for yet; in your first reply to that message I think you specifically deferred it. Here it is: > >Appendix I.2, last sentence. There is a grammatical error in this sentence. > Thanks for doing all the work on this! -- Andreas > > > Thanks in advance, > > Stan Devitt > Math Working Group. > > > errata and comments, chapters 2 and 4 > > > > From: Andreas Strotmann (Strotmann@rrz.uni-koeln.de) > > Date: Thu, May 08 2003 > > > >Message-ID: <3EBA6CCD.10306@rrz.uni-koeln.de> > >Date: Thu, 08 May 2003 16:42:21 +0200 > >From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de> > >To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de> > >CC: www-math@w3.org > >Subject: errata and comments, chapters 2 and 4 > > > > > >Hi, > > > >I've finally had some time to some systematic proof reading. Here's a > >preliminary result. > > > >-- Andreas > > > >========== > > > >2.1.3, third paragraph, starts > > > >> A number of functions and operations require one or more quantifiers > >> to be well-defined. > > > >It should be 'qualifier', not 'quantifier'. > > > > > >2.1.4, second paragraph > > > >> and should not require additional arguments or quantifiers to be fully > >> specified. > > > >Again, this should probably be 'qualifier', not 'quantifier'. > > > > > > > >2.4.5, third paragraph. > > > > > The |id| is also used in this context. > > > >should read > > > > > The id attribute is also used in this context. > > > > > > > >4.2.1, list of categories > > > >Move the last category listed (symbols and constants) to the first > >position in the list. Usually, lists like this are sorted from simplest > >to most complex concepts. > > > >4.2.1.1, first paragraph > > > > > Numbers and symbols are marked by the /token/ elements |cn| and |ci|. > > > >add 'respectively'. > > > >> More elaborate constructs such as sets, vectors and matrices are also > >> marked using elements > > > >'marked up' instead of 'marked'? > > > >4.2.1.3 (whole paragraph) > > > >Mention the extra complication of qualifiers and declarations that > >change the basic pattern of <apply> op a b ... </apply>. This has > >become necessary since qualifiers are no longer tied to specific values > >of 'op' but available for use with user-defined operators, for example. > > > > Discussions have been added in the text to > > > > > > >4.2.1.7 second paragraph > > > >> This is typically an |apply|, but can also be any container element. > > > >It may in principle also be an empty element denoting a constant. (This > >applies to 4.2.2.2 lambda as well) > > > >4.2.1.7 > > > >Note that the lambda construct can be used with zero bvar elements to > >construct a 0-ary function (like random()). The way I read it, this > >paragraph allows this to happen (n=0), but implementers may miss this > >special case if it is not made explicit. (This applies to 4.2.2.2 lambda > >as well) > > > >4.2.1.8 > > > >This currently mentions the use of qualifiers only with predefined > >MathML operators. It should also mention that it is possible to use > >qualifiers in any and all apply elements, including those that have > >csymbols or ci's or even compound first elements. The set example should > >mention that there are other similar cases where bvar qualifiers may be > >used (if there are any, that is -- matrix should be one such case, in my > >mind, as in A = matrix(a_ij) binding variables i and j). > > > >4.2.2.2 matrix > > > >matrix and/or matrix-row should allow the use of bvars and condition or > >domainofapplication qualifiers to specify common notions like matrix A > >:= (a_ij)_i=1..n,j=1..m: > ><matrix> > > <bvar> ... i ... </bvar> > > <domainofapplication> > > <interval> ...0... ...n... </interval> > > </domainofapplication> > > <matrixrow> > > <bvar>...j...</bvar> > > <condition> > > ...0<j<m+1... > > </condition> > > <apply> ...a... ...i... ...j... </apply> > > </matrixrow> > ></matrix> > > > >This applies to vectors, too. > > > >4.2.2.3 > > > >mention again that declare is only allowed at the top-level. > > > >4.2.3.1, third paragraph (arities list) > > > >There appear to be exceptions to this rule. > > > >- The spec contains an example where a missing argument is interpreted > >as a curried expression, that is the apply missing the argument is > >interpreted as standing for a function in that missing argument. > > > >- binary and n-ary functions often induce an easy generalization to > >variable-binding operators, e.g. plus -> sum, times -> product, and -> > >forall, or -> exists. In these cases, the operators would be called > >with a single argument only (despite being binary, for example), and > >with a bvar and a condition qualifier. > > > >4.2.3.1, fourth paragraph "The one exception..." > > > >mention again that declare is only allowed at the top-level (I know that > >I used to mis-interpret this sentence to mean that a declare can be > >inserted at any level of nesting). > > > >4.2.3.2 > > > >I notice that domainofapplication is listed as a qualifier here. Good. > >Make sure you mention that in 4.4.2.15. > > > >The second example uses <fn>. This is deprecated and should not be used > >in an example that does not serve as a counter-example. > > > >As mentioned earlier, I propose to deprecate the use of interval as a > >qualifier. This would cause several changes in this section. > > > >int; sum and product: > > > >> When used with |int|, each qualifier schema is expected to contain a > >> single child schema; otherwise an error is generated. > > > >This is only true if no interval qualifier schema is allowed (which I > >advocate). Intervals tend to have two children. > > > >diff: > > > >The example uses fn, which is deprecated. > > > >partialdiff: > > > >Why is the optional degree qualifier available for partialdiff but not > >diff? That seems inconsistent to me. > > > >forall, exists: > > > >I have argued elsewhere that it is not necessary to require at least one > >bvar qualifier to go with these. > > > >4.2.4, third paragraph > > > >> It is an error to enclose a relation in an element other than |apply| > >> or |reln|. > >> > >Not true. Here is a counter-example that you'll find in my dissertation: > > > > <set> <lt/> <gt/> <eq/> <neq/> <leq/> <geq/> </set> > > > >I recommend removing this sentence, as I can easily imagine more cases > >like this with other containers. > > > >unary/binary/... : the discussion above applies here too. > > > >4.2.5. > > > >mention that conditions can be used with arbitrary "heads" of their > >apply, just like bvars. > > > >4.2.5.1, second example > > > >use MathML constant symbols instead of OpenMath csymbols for the sets N > >and P. > > > >4.3.2.5 nargs: > > > >add a possible value to specify that the declared operator follows the > >model of quantifiers or sum/prod/int/max/min/... 'Binder' is used in > >OpenMath, 'quantifier' or 'generalized-quantifier' might be > >alternatives, too. > > > >4.4.2.1.1 last paragraph > > > >Mention user-defined symbols in the context of qualifiers, too. > > > >4.4.2.4.1, last sentence > > > >> The |interval| element expects /either/ two child elements that > >> evaluate to real numbers /or/ one child element that is a |condition| > >> defining the |interval|. > >> > >the condition qualifier has to be used with bvars according to earlier > >parts of the spec. Thus, we actually have 4 distinct possibilities: > > > >a) interval(a,b) > >b) interval(bvar(x),condition(p)) > >c) interval(lambda(bvar(x),p)) > >d) interval(p) where p is a unary predicate. > > > >However, I think that b) through d) are covered by the set and > >domainofapplication elements already, so that there is little to be > >gained from allowing them in addition to a). > > > >4.4.2.7.1. > > > >mention that reln is deprecated. > > > >4.4.2.9.1 > > > >it should be possible to use lambda to construct nullary functions (that > >is, use lambda with zero or more bvars). mention also the possible use > >of domainofapplication etc. > > > >4.4.2.9.3 > > > >shouldn't the default rendering be more like \lambda x. f ? > > > >4.4.2.11 > > > >shouldn't ident have an optional argument giving the domain it is the > >identity function for? Default rendering of ident(D) would then be > id_D. > > > >4.4.2.15 > > > >mention that domainofapplication is a qualifier element. > > > >4.4.2.16 > > > >I'm not sure that it is a good idea to disallow degenerate versions of > >piecewise that have no piece elements at all. When this kind of > >expression is generated by computer, I can easily imagine cases where > >somewhere in the simplification chain for a smooth function description > >it might go through just such a form, to be simplified in the next step. > > However, one could imagine a case where the knowledge for this extra > >simplification step that strips away a piecewise with a single otherwise > >child resides in an external application... Even the completely > >degenerate form of an empty piecewise expression could easily come up in > >a chain of reasoning that proves that a certain function definition > >leads to an empty domain. > > > [JSD] These degenerate cases are now allowed. > > > > > > >4.4.3.5 > > > >add a unary minus example. > > > >4.4.3.17, 4.4.3.18 > > > >again, I have argued elsewhere that requiring a bvar is unnecessary as > >there are common examples where one does not appear. > > > >4.4.5.1.1 > > > >The domain of integration may actually be specified in more different > >ways: lowlimit/uplimit, interval (which should be deprecated), > >domainofapplication, condition (with bvar(s)). > > > >Mention that the bvar element specifies the integration variable. > > > >4.4.5.1.2 > > > >If the use of interval as a qualifier is deprecated (as it should), the > >second example needs to be changed so that the interval element is > >wrapped with a domainofapplication. > > > >4.4.5.2.2 > > > >add a degree example. > > > >I'm surprised that diff is only for single-variable differentiation. I > >thought that it would also stand for total differentiation in multiple > >variables. In this case, optional degree arguments and the possible > >two-argument variant specified in partialdiff should apply here, too. > > > >4.4.5.6.1 > > > >mention that bvar can be used with user-defined or even compound > "heads". > > > >4.4.5.6.3 > > > >the default rendering of the first example should be $\frac{d^2 > x^4}{dx^2}$ > > > >4.4.5.8/9/10 > > > >add default renderings with \nabla, as in the case of the laplacian. > > > >4.4.6.9/10 > > > >the default renderings in 4.4.6.9 and .10 need to be swapped. > > > >4.4.6.13 > > > >we're clearly missing a cartesianpower element to represent $\R^n$, > >n-dimensional real vector space -- although > >cartesianproduct(bvar(i),condition(0<i<n),reals) would work, too ;-) > > > >4.4.7.1, .2 > > > >we can also use domainofapplication here. Mention also that a function > >argument without a bvar qualifier is possible. > > > >Appendix I.2, last sentence. There is a grammatical error in this > sentence. > > > >
Received on Friday, 11 July 2003 10:41:14 UTC