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

Date: Wed, 18 Jun 2003 16:21:44 +0200

Message-ID: <3EF07578.4020505@rrz.uni-koeln.de>

To: Stan Devitt <jsdevitt@stratumtek.com>

CC: www-math@w3.org

Date: Wed, 18 Jun 2003 16:21:44 +0200

Message-ID: <3EF07578.4020505@rrz.uni-koeln.de>

To: Stan Devitt <jsdevitt@stratumtek.com>

CC: www-math@w3.org

Stan, I'm glad that I could help. > A considerable number of the points you have raised > have been driven by the need to explain how to > deal properly with bound variables, > the domainofapplication, and its interaction with > the other qualifiers. Yes, I realized that, too, and I think it was the sheer number of places that this cropped up that made me late for the second half of my comments. I'm glad to hear that you have been able to address those points that I raised after the deadline, which were (almost?) all within this general topic. > We have been somewhat constrained by the fact that > the purpose of this revision of the specification to > address errata and/or to clarify ambiguities, but > within that context feel we have been able to make > considerable strides in addressing all of your points. > I think you will find that even the points you raised > after the official close to last call have been addressed > by the outcome. Yes, I think I realized a bit too late that a second edition somewhat constrains the changes you can make to the document. I hope you'll flag those changes that you didn't make because of this constraint to keep them active for the next fuller revision. > Those which were clearly editorial will be marked > as such below. The discussions of the more substantive > issues will either include text outlining the outcome > of the discussion they provoked, or will refer to > other messages where that discussion is provided. There are some places where you provide only a very brief description of what you have done to address the issue, but note at the same time that the solution you came up with required a few non-obvious changes in other places. I would like to offer proofreading the fixes, too, just in case some inadvertant inconsistencies have cropped up -- I should have done that the last time you extended bvar on my request and the consistency issues I pointed out this time came up as a result. > Once again, thank you for your time and effort. > It has really helped. > Stan Devitt You're welcome. It was my pleasure. Below, there are two items that I did not see a response to, plus one item where I felt that the solution you described missed a crucial point that I had tried to make. A couple of minor questions that I'd be happy with any way they're answered, plus a few things that you say you will answer separately make up the balance of this follow-up. For all the rest (and there were lots!), you have done an excellent job. Thanks! -- Andreas > > > > From: Andreas Strotmann (Strotmann@rrz.uni-koeln.de) > > Date: Thu, May 08 2003 > > Subject: errata and comments, chapters 2 and 4 > > > > > 4.2.3.2 > > > As mentioned earlier, I propose to deprecate the use of interval as a > > qualifier. This would cause several changes in this section. > > The interval was retained as it is a natural way to represent > intervals along a curve. It makes it easier to come up with > appropriate presentations instead of having to decipher a complicated > domainofapplication expression. > > However, wording has been added to clarify that it is really an > abbreviation for a suitable "domainofapplication". This is a good thing to do as such, but doesn't address the real issue wrt. interval qualifiers vs. constructors that I had raised in earlier messages and that I was referring to here. That issue is with *ambiguity*, which you mentioned in your response to me as the second main purpose of this second edition errors. There are cases imaginable (though admittedly rare in practice) where it may not be possible to disambiguate between a reading of an <interval>..</interval> as a constructor of an interval on the one hand and the reading of the same expression as a qualifier of the surrounding apply on the other. I think I posted examples earlier, and showed that these different readings lead to radically different semantics, which makes this a serious problem in my book. One possible way to avoid this ambiguity is to deprecate one of these two uses, and since the interval qualifier can easily be replaced, that's the one I recommended for depracation. Also, this was my *only* reason for this recommendation - I was quite aware of the usefulness of these different ways of representing the domainofapplication concept. The problem with the solution you describe is that, though it nicely ties the different ways of specifying domains of application together, it in no way addresses the ambiguity problem. I admit, however, that the easy way out that I suggested (i.e. deprecation) is perhaps a bit too radical for a second edition, besides having the disadvantage of breaking old code and examples. An alternative solution could take the form of specifying an algorithm that is guaranteed to determine, from context, whether an interval element is a qualifier or a constructor. This algorithm would probably require some reasonable restrictions on the use of interval as a qualifier; here is a sample restriction that would make such a decision algorithm easy to specify: "as a *qualifier*, an interval element *must* be accompanied by a bvar sibling, which it must *precede*." (This would change the standard order of qualifiers, I suspect, but would guarantee easy disambiguation. Any interval appearing in this configuration is already guaranteed to be a qualifier by the current MathML spec, since qualifiers must precede all regular arguments, and an interval head element must be a constructor). > > diff: > > > The example uses fn, which is deprecated. > > We have introduced a "function" type value for use with the type > attribute and used it in place of "fn". Good. Is it possible to use both a "function" and a "real" type value simultaneously to denote a real function? > > partialdiff: > > > Why is the optional degree qualifier available for partialdiff but not > > diff? That seems inconsistent to me. > > The diff operator is explicitly univariate and the degree can > always be inferred from the degree of the bound variable. Not for display it can't: d/dx d/dy d/dz f is usually written d^3 f/dx dy dz, so that you have exactly the same problem as for partialdiff. > The partialdiff's degree qualifier enables one to more > easily write the total degree in d^(m+n)/(dx^m dy^n) > or d^3/(dx dy dz) without requiring the implementation of > software to introduce the algebraic > arithmetic necessary to compute the total degree. I take this answer to mean that this kind of change would not be appropriate for a second edition. That's fine with me. > > forall, exists: > > > I have argued elsewhere that it is not necessary to require at least > one > > bvar qualifier to go with these. > > This requirement has been relaxed as you suggest > so that by analogy with int() or sum(), you can now write > > Forall( domainofapplication(C) , f ) > > where f is a function evaluated at points of the domain and > plays the role of an assertion. > > The domainofapplication qualifier is now treated uniformly > across all operators that support domainofapplication > and its shortcut notations. Thus in addition to the above > we can also write: > > Forall( bvar(x) , domainofapplication( > set(bvar(X),condition(X>=1 andX<=5)) , f(x) ) > > which can be shortened to (depending on the circumstances > and preferences) > > Forall( bvar(x) , condition( x >=1 and x <= 5 ) , f(x) ) > Forall( interval(1,5) , f ) > Forall( bvar(x) , lowlimit(1), uplimit(5) , f(x) ) > > Each shortened forms maps more naturally to > particular presentations. Depending on the operator, > one particular shortened form may better reflect common > usage than another (e.g. int and lowlimit, uplimit), > but by making all the short forms valid the treatment has > become consistent across the board. Excellent! > > > unary/binary/... : the discussion above applies here too. > > > 4.2.5. > > Fixed. > > > mention that conditions can be used with arbitrary "heads" of their > > apply, just like bvars. Here, I see only one 'fixed' but two suggestions. ?? > > 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. > > The type attribute could be used to specify this, or alternatively > a definitionURL, so we have left this as is. So, did you add this kind of type attribute (along with the new one for 'function' you mentioned earlier)? > > 4.4.2.15 > > > mention that domainofapplication is a qualifier element. ?? > > 4.4.5.8/9/10 > > > add default renderings with \nabla, as in the case of the laplacian. > > To be answered separately . > > > 4.4.6.9/10 > > > the default renderings in 4.4.6.9 and .10 need to be swapped. > > To be answered separately. > > > > Appendix I.2, last sentence. There is a grammatical error in this > sentence. > > To be answered separately.Received on Wednesday, 18 June 2003 10:21:54 UTC

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