Re: Suggested Corrections to 4.2.3.2 and 4.4.2.15

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