# Re: Suggested Corrections to 4.2.3.2 and 4.4.2.15

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>


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.

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