Re: errata and comments, chapters 2 and 4

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