- From: Stan Devitt <jsdevitt@stratumtek.com>
- Date: Wed, 09 Jul 2003 17:58:46 -0400
- To: www-math@w3.org
Andreas,
Going over your message on chapter 2 and 4 on May 8th, I think we have
now gone through all the issues. I have structured this note as a
summary of the current status and the outcome on each open issue. I
have included a copy of the original note for completeness.
Thee small editorial changes have all been made except in some instances
that boil down to editorial style. I only discuss here the major points
that are not marked in our records as confirmed closed.
According to our records, the main items arising from this message that
we have not got confirmation on are:
1. proposed deprecation of interval. (our issue# 13-14)
OUTCOME: We have elected to keep interval as both a qualifier and a
regular object, but have described how to resolve ambiguitie that may arise.
2. possible values of the type attribute (our issue# 13-16)
OUTCOME: We have clarified that the type attribute value is an
arbitrary string and so can be, for example, a space or comma separated
list of other common values. We have added a "function" attribute value
to the list of known types to help avoiding use of the deprecated fn
container name.
3. partialdiff versus diff structure (our issue# 13-17)
OUTCOME: We have retained the univariate structure of diff. This helps
to ensure there is no confusion between which notation to use, and
having clarified that qualifiers can be used with user defined symbols,
the functionality and interpretation you are seeking can be formalized
without needing to use diff. This should be flagged as a candidate for
review in the future as some such conventions develop and stabilize.
4. 4.2.4 the wording about binary relations. (our issue# 13-20)
OUTCOME: This wording has been revised along the lines you suggest.
We have also made it clear that more than one classification may be
possible for an operator.
5. 4.3.2.5 introduction of a type attribute value to denote
nargs. (our issue# 13-23)
OUTCOME: Since the type attribute takes arbitrary strings as values
this is already permitted in the present spec. We did not formalize
"nargs" as a possible value as we were wanting to focus more on
mathematical types than on structural types;. More needs to be said on
facilitating types and that will appear in a forthcoming note on that topic.
6. 4.4.2.11 ident having a "domain". (our issue# 13-30)
OUTCOME: We did not make any formal change to ident in this regard.
We did however follow your suggestions to clarify the use of lambda, in
particular, that you may associate a domain with a function so that
<declare>
<ci>IDENT</ci>
<lambda>
<ident/>
<domainofapplication><ci type="set">C</ci></domainofapplication>
</lambda>
</declare>
creates just such a named function.
7. 4.4.2.16 degenerate cases for piecewise (our issue# 13-32)
OUTCOME: We have relaxed these constraints so that the degenerate
cases may now occur.
Once again, confirmation from you that we have addressed these major
points will help us to track these items properly.
Thanks in advance,
Stan Devitt
Math Working Group.
> errata and comments, chapters 2 and 4
>
> From: Andreas Strotmann (Strotmann@rrz.uni-koeln.de)
> Date: Thu, May 08 2003
>
>Message-ID: <3EBA6CCD.10306@rrz.uni-koeln.de>
>Date: Thu, 08 May 2003 16:42:21 +0200
>From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
>To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
>CC: www-math@w3.org
>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'.
>
>
>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'.
>
>
>
>2.4.5, third paragraph.
>
> > The |id| is also used in this context.
>
>should read
>
> > 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.
>
>4.2.1.1, first paragraph
>
> > Numbers and symbols are marked by the /token/ elements |cn| and |ci|.
>
>add 'respectively'.
>
>> More elaborate constructs such as sets, vectors and matrices are also
>> marked using elements
>
>'marked up' instead of 'marked'?
>
>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.
>
Discussions have been added in the text to
>
>
>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)
>
>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)
>
>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).
>
>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.
>
>4.2.2.3
>
>mention again that declare is only allowed at the top-level.
>
>4.2.3.1, third paragraph (arities list)
>
>There appear to be exceptions to this rule.
>
>- 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.
>
>- 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.
>
>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).
>
>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.
>
>As mentioned earlier, I propose to deprecate the use of interval as a
>qualifier. This would cause several changes in this section.
>
>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.
>
>diff:
>
>The example uses fn, which is deprecated.
>
>partialdiff:
>
>Why is the optional degree qualifier available for partialdiff but not
>diff? That seems inconsistent to me.
>
>forall, exists:
>
>I have argued elsewhere that it is not necessary to require at least one
>bvar qualifier to go with these.
>
>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.
>
>unary/binary/... : the discussion above applies here too.
>
>4.2.5.
>
>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.
>
>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.
>
>4.4.2.1.1 last paragraph
>
>Mention user-defined symbols in the context of qualifiers, too.
>
>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:
>
>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).
>
>4.4.2.7.1.
>
>mention that reln is deprecated.
>
>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.
>
>4.4.2.9.3
>
>shouldn't the default rendering be more like \lambda x. f ?
>
>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.
>
>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.
>
[JSD] These degenerate cases are now allowed.
>
>
>4.4.3.5
>
>add a unary minus example.
>
>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.
>
>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.
>
>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.
>
>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.
>
>4.4.5.6.1
>
>mention that bvar can be used with user-defined or even compound "heads".
>
>4.4.5.6.3
>
>the default rendering of the first example should be $\frac{d^2
x^4}{dx^2}$
>
>4.4.5.8/9/10
>
>add default renderings with \nabla, as in the case of the laplacian.
>
>4.4.6.9/10
>
>the default renderings in 4.4.6.9 and .10 need to be swapped.
>
>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 ;-)
>
>4.4.7.1, .2
>
>we can also use domainofapplication here. Mention also that a function
>argument without a bvar qualifier is possible.
>
>Appendix I.2, last sentence. There is a grammatical error in this
sentence.
>
Received on Thursday, 10 July 2003 01:00:22 UTC