- From: Stan Devitt <jsdevitt@stratumtek.com>
- Date: Tue, 17 Jun 2003 14:07:16 -0400
- To: www-math@w3.org
Andreas,
Thank you very much for your very substantial review.
You have obviously looked at things in great depth
and collectively your suggestions have had considerable
impact and caught some very important issues.
One of the reasons for the long delay in responding to
this message (and the others) is that we have been
working through the suggestions and the consequences
thoroughly. While we have not made every change you
have suggested exactly in the form suggested, we
hope we have addressed all the points raised.
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.
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.
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.
Please read on for the details. I'll be responding
directly to your other emails as well in separate
messages.
Can you please respond back to the group
acknowledging the resolutions outlined below?
Once again, thank you for your time and effort.
It has really helped.
Stan Devitt
> errata and comments, chapters 2 and 4
> From: Andreas Strotmann (Strotmann@rrz.uni-koeln.de)
> Date: Thu, May 08 2003
> Subject: errata and comments, chapters 2 and 4
> Hi,
> I've finally had some time to some systematic proof reading. Here's a
> preliminary result.
> -- Andreas
> ==========
> 2.1.3, third paragraph, starts
> > A number of functions and operations require one or more quantifiers
> > to be well-defined.
> It should be 'qualifier', not 'quantifier'.
Fixed.
> 2.1.4, second paragraph
> > and should not require additional arguments or quantifiers to be fully
> > specified.
> Again, this should probably be 'qualifier', not 'quantifier'.
Fixed.
> 2.4.5, third paragraph.
> > The |id| is also used in this context.
> should read
Fixed.
> > The id attribute is also used in this context.
> 4.2.1, list of categories
> Move the last category listed (symbols and constants) to the first
> position in the list. Usually, lists like this are sorted from simplest
> to most complex concepts.
We left the list as is since this is a second revision to the spec
and we wanted to minimize changes against the previous versions.
> 4.2.1.1, first paragraph
> > Numbers and symbols are marked by the /token/ elements |cn| and |ci|.
> add 'respectively'.
We left this as is. We wanted to minimize change and the token list
as it stands is not exhaustive anyway. A more precise statement
should try to be exhaustive and would not be appropriate in the
introduction.
> > More elaborate constructs such as sets, vectors and matrices are also
> > marked using elements
> 'marked up' instead of 'marked'?
Left as is, to minimize change.
> 4.2.1.3 (whole paragraph)
> Mention the extra complication of qualifiers and declarations that
> change the basic pattern of <apply> op a b ... </apply>. This has
> become necessary since qualifiers are no longer tied to specific values
> of 'op' but available for use with user-defined operators, for example.
We have left this discussion in section 4.2.1.8 and changed the
wording there to be more comprehensive.
> 4.2.1.7 second paragraph
> > This is typically an |apply|, but can also be any container element.
> It may in principle also be an empty element denoting a constant. (This
> applies to 4.2.2.2 lambda as well)
This phrasing has been clarified.
> 4.2.1.7
> Note that the lambda construct can be used with zero bvar elements to
> construct a 0-ary function (like random()). The way I read it, this
> paragraph allows this to happen (n=0), but implementers may miss this
> special case if it is not made explicit. (This applies to 4.2.2.2 lambda
> as well)
Fixed.
> 4.2.1.8
> This currently mentions the use of qualifiers only with predefined
> MathML operators. It should also mention that it is possible to use
> qualifiers in any and all apply elements, including those that have
> csymbols or ci's or even compound first elements. The set example should
> mention that there are other similar cases where bvar qualifiers may be
> used (if there are any, that is -- matrix should be one such case, in my
> mind, as in A = matrix(a_ij) binding variables i and j).
Fixed. We found we were able to fit in this suggestion
without breaking any of the old uses.
> 4.2.2.2 matrix
> matrix and/or matrix-row should allow the use of bvars and condition or
> domainofapplication qualifiers to specify common notions like matrix A
> := (a_ij)_i=1..n,j=1..m:
> <matrix>
> <bvar> ... i ... </bvar>
> <domainofapplication>
> <interval> ...0... ...n... </interval>
> </domainofapplication>
> <matrixrow>
> <bvar>...j...</bvar>
> <condition>
> ...0<j<m+1...
> </condition>
> <apply> ...a... ...i... ...j... </apply>
> </matrixrow>
> </matrix>
> This applies to vectors, too.
Fixed.
> 4.2.2.3
> mention again that declare is only allowed at the top-level.
Fixed.
> 4.2.3.1, third paragraph (arities list)
> There appear to be exceptions to this rule.
A sentence has been added pointing this out.
> - The spec contains an example where a missing argument is interpreted
> as a curried expression, that is the apply missing the argument is
> interpreted as standing for a function in that missing argument.
The intended interpretation of this example and a lambda based
alternative has been provided.
> - binary and n-ary functions often induce an easy generalization to
> variable-binding operators, e.g. plus -> sum, times -> product, and ->
> forall, or -> exists. In these cases, the operators would be called
> with a single argument only (despite being binary, for example), and
> with a bvar and a condition qualifier.
Example of minus being both binary and unary is included in the
description.
> 4.2.3.1, fourth paragraph "The one exception..."
> mention again that declare is only allowed at the top-level (I know that
> I used to mis-interpret this sentence to mean that a declare can be
> inserted at any level of nesting).
Deleted. This was easily misconstrued to read that declare was allowd
in the body of applies.
> 4.2.3.2
> I notice that domainofapplication is listed as a qualifier here. Good.
> Make sure you mention that in 4.4.2.15.
> The second example uses <fn>. This is deprecated and should not be used
> in an example that does not serve as a counter-example.
Fixed.
> 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".
> int; sum and product:
> > When used with |int|, each qualifier schema is expected to contain a
> > single child schema; otherwise an error is generated.
> This is only true if no interval qualifier schema is allowed (which I
> advocate). Intervals tend to have two children.
Deleted the sentence.
> 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".
> 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.
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.
> 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.
> 4.2.4, third paragraph
> > It is an error to enclose a relation in an element other than |apply|
> > or |reln|.
> >
> Not true. Here is a counter-example that you'll find in my dissertation:
> <set> <lt/> <gt/> <eq/> <neq/> <leq/> <geq/> </set>
> I recommend removing this sentence, as I can easily imagine more cases
> like this with other containers.
Fixed.
> 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.
> 4.2.5.1, second example
> use MathML constant symbols instead of OpenMath csymbols for the sets N
> and P.
Reasonable suggestion, but we have left the example as is
partly to retain its value showing external references.
> 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.
> 4.4.2.1.1 last paragraph
> Mention user-defined symbols in the context of qualifiers, too.
fixed. (also ci's "declared")
> 4.4.2.4.1, last sentence
> > The |interval| element expects /either/ two child elements that
> > evaluate to real numbers /or/ one child element that is a |condition|
> > defining the |interval|.
> >
> the condition qualifier has to be used with bvars according to earlier
> parts of the spec. Thus, we actually have 4 distinct possibilities:
The wording in the spec was trying to indicate that if an
interval was not adequate to describe your set then you
could use one of the other qualifiers. The interval
should not have had a condition as a content model.
This error has been fixed here and in the grammar.
> a) interval(a,b)
> b) interval(bvar(x),condition(p))
> c) interval(lambda(bvar(x),p))
> d) interval(p) where p is a unary predicate.
> However, I think that b) through d) are covered by the set and
> domainofapplication elements already, so that there is little to be
> gained from allowing them in addition to a).
Agreed and fixed.
> 4.4.2.7.1.
> mention that reln is deprecated.
fixed.
> 4.4.2.9.1
> it should be possible to use lambda to construct nullary functions (that
> is, use lambda with zero or more bvars). mention also the possible use
> of domainofapplication etc.
This content model has been relaxed to allow qualifiers
as in lambda( bvar(x), qualifier , f(x) )
> 4.4.2.9.3
> shouldn't the default rendering be more like \lambda x. f ?
The notation used for lambda expressions is certainly not
as common, but understandable and so we have left it as is.
If changed, it will be changed systematically throughout the spec.
> 4.4.2.11
> shouldn't ident have an optional argument giving the domain it is the
> identity function for? Default rendering of ident(D) would then be
id_D.
The definitionURL (together with a domainofapplication)
accommodates this need so we have not changed it.
> 4.4.2.15
> mention that domainofapplication is a qualifier element.
> 4.4.2.16
> I'm not sure that it is a good idea to disallow degenerate versions of
> piecewise that have no piece elements at all. When this kind of
> expression is generated by computer, I can easily imagine cases where
> somewhere in the simplification chain for a smooth function description
> it might go through just such a form, to be simplified in the next step.
> However, one could imagine a case where the knowledge for this extra
> simplification step that strips away a piecewise with a single otherwise
> child resides in an external application... Even the completely
> degenerate form of an empty piecewise expression could easily come up in
> a chain of reasoning that proves that a certain function definition
> leads to an empty domain.
fixed.
> 4.4.3.5
> add a unary minus example.
left as is ... It's absence has not caused any problems.
> 4.4.3.17, 4.4.3.18
> again, I have argued elsewhere that requiring a bvar is unnecessary as
> there are common examples where one does not appear.
Fixed.
> 4.4.5.1.1
> The domain of integration may actually be specified in more different
> ways: lowlimit/uplimit, interval (which should be deprecated),
> domainofapplication, condition (with bvar(s)).
> Mention that the bvar element specifies the integration variable.
Fixed.
> 4.4.5.1.2
> If the use of interval as a qualifier is deprecated (as it should), the
> second example needs to be changed so that the interval element is
> wrapped with a domainofapplication.
Changed the example to use interval without a bound variable.
> 4.4.5.2.2
> add a degree example.
> I'm surprised that diff is only for single-variable differentiation. I
> thought that it would also stand for total differentiation in multiple
> variables. In this case, optional degree arguments and the possible
> two-argument variant specified in partialdiff should apply here, too.
This was as far as we could go without feedback
on different approaches to multivariate calculus.
The extension mechanisms allow this experimentation
to take place.
> 4.4.5.6.1
> mention that bvar can be used with user-defined or even compound "heads".
Reworded.
> 4.4.5.6.3
> the default rendering of the first example should be $\frac{d^2
x^4}{dx^2}$
Fixed.
> 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.
> 4.4.6.13
> we're clearly missing a cartesianpower element to represent $\R^n$,
> n-dimensional real vector space -- although
> cartesianproduct(bvar(i),condition(0<i<n),reals) would work, too ;-)
The condition now works as suggested here.
> 4.4.7.1, .2
> we can also use domainofapplication here. Mention also that a function
> argument without a bvar qualifier is possible.
Fixed.
> Appendix I.2, last sentence. There is a grammatical error in this
sentence.
To be answered separately.
Received on Tuesday, 17 June 2003 14:05:01 UTC