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

Date: Thu, 19 Jun 2003 18:08:39 +0200

Message-ID: <3EF1E007.7050604@rrz.uni-koeln.de>

To: Stan Devitt <jsdevitt@stratumtek.com>

CC: www-math@w3.org

Date: Thu, 19 Jun 2003 18:08:39 +0200

Message-ID: <3EF1E007.7050604@rrz.uni-koeln.de>

To: Stan Devitt <jsdevitt@stratumtek.com>

CC: www-math@w3.org

Stan, I'm sorry, but one of the points I tried to make is still open. The resolution you offer does nicely address important issues that I believe I did make at some point, but it does not appear to address the specific problem with this particular case that I had had in mind (see below). The other issue in this post has been resolved. Best regards, -- Andreas Stan Devitt wrote: > > Andreas, > > This again is in response to your messages from the last call review of > the working draft. > > To assist us in preparing a Last Call report, we would appreciate it if > you could post a brief message acknowledging we have responded to the > points you've raised. > > Stan Devitt > Math Working Group > > > > * From: Andreas Strotmann > > * Date: Apr 23 2003 > > > 4.2.3.2: > > > I would like to suggest removing one line from the example quoted below > > from section 4.2.3.2, namely, the line containing the bvar qualifier: > > > " It is also valid to use qualifier schema with a function not applied > > to an argument. For example, a function acting on integrable functions > > on the interval [0,1] might be denoted: > > <fn> > > <apply> > > <int/> > > <bvar><ci>x</ci></bvar> > > <lowlimit><cn>0</cn></lowlimit> > > <uplimit><cn>1</cn></uplimit> > > </apply> > > </fn> > > " > > As you have noted elsewhere in your comments, this is actually > intended to be a curried expression, and not {\int_0^1 1 dx} > > This has been clarified in the remarks by adding an example of how to > accomplish the same thing without the deprecated fn by using a lambda > expression. My point was that the bvar defeats the purpose of getting the semantics of a curried expression in this example since it marks a scope barrier for the bound variable x. Applying this example (the one *with* the bvar) to an expression with a free variable x must not bind them all of a sudden (otherwise, the question 'does such an application contain free occurrences of variable x' would have two different correct answers, i.e. you get a problematic ambiguity). Therefore, I was suggesting to just remove the bvar in order to get a nice and clean curried form of the integral operator, because in that case there'd be no scope barrier to mess things up. However, this would require a functional argument to be passed to the "curried" interval. I didn't quite understand whether your answer above resolves this issue or not. > > > I found that Maple quite reasonably interprets the apply element of the > > example as it stands now as $\int_0^1 dx$, which evaluates to 1. > Given my interpretation above, Maple's is actually the correct behaviour, even though it violates the interpretation you give here. > > The problem is that the correct way to represent the concept of > > integrals over a particular interval is along the lines of the example > > in section 4.4.2.15 (Domain of Application): > > > "The integral of a function f over an arbitrary domain C . > > <apply> > > <int/> > > <domainofapplication> > > <ci> C </ci> > > </domainofapplication> > > <ci> f </ci> > > </apply> > > " > > In several places throughout the text we have clarified that the most > general qualifier is the domainofapplication an that the others should > be thought of as abbreviations. We have made this systematic throughout > the text across various examples that you refer to in your note that > were artificially restricte to one or other of the shortened forms so > that qualifiers are now treated more uniformly. Note that this does not > break any legacy data. > Excellent -- but this was not the point (this time). > We did not deprecate the shorthand notations as they > serve two other important roles. > > 1. New users looking for a representation of \int_0^1 f(x) dx, > more quickly recognize the short form with uplimit and lowlimit > and may not be prepared to formalize this into a domain of application. > (It matches how they are used to writing their mathematics.) > > 2. Each of the shortened forms maps naturally to a particular > presentation. (e.g., upper and lower bounds with bound variables, > or intervals to {\int_0^1 f } or bvar and condition of set > membership in C to {\int_{x\inC} f(x) dx }. ) > Agreed. > > > using a unary function as an argument to the integral operator. The way > > the current example that I suggest fixed here stands, variables x in the > > argument to such a function would be crossing a variable binding barrier > > in a rather peculiar way that I don't think any semantics formalism > > could possibly allow in a systematic fashion. > > > Several examples discussing how domainofapplication and the > other representations of domain of integration are handled. > > This representation corresponds roughly to the common usage > {\int_C f} and the notion of integrating a "function" over > a domain. > > The underlying problem aluded to here is how to decide which > bound variable of the domain corresponds to which bound variable > of the integral and it surfaces in examples where the the > domainofapplication and the function are actually defined. Yes and no. Yes, I did mention this problem somewhere, but no, in the context of a discussion of the curried interval, that was not the underlying problem I was thinking of -- see above. > > We have clarified this by using your suggestion of viewing the > domain as an "implicit" cartesian product in which the order > of the bound variables maps directly to the order of the > terms in the cartesian product. > Excellent -- but this is the solution to a different, though important, problem. I don't understand yet whether or not you have addressed the issue of the bvar in the curried integral example.Received on Thursday, 19 June 2003 12:09:00 UTC

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