W3C home > Mailing lists > Public > www-math@w3.org > July 2003

Re: errata and comments, chapter C (first installment)

From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
Date: Fri, 11 Jul 2003 14:18:03 +0200
Message-ID: <3F0EAAFB.1000906@rrz.uni-koeln.de>
To: Stan Devitt <jsdevitt@stratumtek.com>
CC: www-math@w3.org

Stan,

you guys have clearly done significant work on the issues I raised, and 
the brief descriptions you give of the way that you intend to resolve 
them sound very good to me.  Given how much work these appear to have 
been, and given the apparently extensive changes that have had to be 
made to chapter 4 and C, I would like to offer proof-reading these again 
before a final release of MathML 2, 2nd ed., if you are not planning to 
put the final draft on the web first anyway.

So, please consider all of my questions answered, with a single pair of 
exceptions discussed below where I ask you to reconsider your proposed 
resolution, and with the exception of a minor suggestion that you may 
have overlooked.

 -- Andreas

Stan Devitt wrote:

>
> Andreas,
>
> Continuing with the resolutions:
>
> Again we have worked through all the straight editorial pointers below 
> and will not dwell on them here.
> Also, a number of the points you have below relate to signatures that 
> are missing, off by 1, or generally
> too restrictive..  There has been a full review of the signatures to 
> make them more consistent with
> the possible arities.   In most, but not all, cases we have have 
> changed it as you suggested.  We have
> tried to keep the signatures "informative" so that the types you would 
> usually expect to be found
> in certain positions are visible.    One significant consequence of 
> your questions has been that the
> introduction now discusses a "domainofapp" which stands for 
> "domainofapplication" or any
> of its abbreviations and this is used throughout in the signatures 
> with   (domainofapp,function) -> algebraic
> occurring in quite a few places that it had been missed.
>
> With this in mind, the main issues that you raise and their  
> disposition are shown below.
> As usual, a response acknowledging these outcomes would be most helpful.
>
> Stan Devitt
> Math Working Group.
>
>>
>>   errata and comments, chapter C (first installment)
>>
>> *From:* Andreas Strotmann (/Strotmann@rrz.uni-koeln.de/ 
>> <mailto:Strotmann@rrz.uni-koeln.de?Subject=Re:%20errata%20and%20comments,%20chapter%20C%20%28first%20installment%29&amp;In-Reply-To=&lt;3EBBC21E.9080803@rrz.uni-koeln.de&gt;&amp;References=&lt;3EBBC21E.9080803@rrz.uni-koeln.de&gt;>) 
>>
>> *Date:* Fri, May 09 2003
>>
>> ------------------------------------------------------------------------
>> <mailto:www-math@w3.org?Subject=Re:%20errata%20and%20comments,%20chapter%20C%20%28first%20installment%29&amp;In-Reply-To=&lt;3EBBC21E.9080803@rrz.uni-koeln.de&gt;&amp;References=&lt;3EBBC21E.9080803@rrz.uni-koeln.de&gt;>Subject: 
>> errata and comments, chapter C (first installment)
>>
>
>
>>
>> How about this extra example:  Forall(f, x in image(f), x in 
>> codomain(f)).
>
??

>
>> C.2.2.17  (our issue 14-17)
>>
>> The formal signature is incorrect.  Replace 'algebraic' by 
>> 'anything'. Rationale: you can define a piecewise relation, too, 
>> though admittedly that would be a bit unusual.
>>
>    [JSD]   We have elected to stay with algebraic and distinguish
>    between a standard and "non-standard" use  of the notation  by
>    asking the author to use a definitionURL in the non-standard cases. 

This resolution is inconsistent with others, where an attempt has been 
made to reduce the number of restrictions in the signatures as much as 
possible, whenever that appeared reasonable.

For all intents and purposes, relations simply *are* boolean functions, 
and indeed are more likely than other functions to be defined piecewise, 
e.g.

  relation   strictly_positive(x) := true if x>0, false otherwise.

<diatribe>
This is clearly K-14, and there is absolutely no reason to believe that 
this is 'non-standard' in any way, shape, or form.

This is yet another excellent example why it is extremely dangerous to 
try and enforce arbitrary restrictions on allowable arguments for 
mathematical formulas. I strongly recommend a policy of 'in dubio pro 
reo' -- i.e. when in doubt, it's allowed.
</diatribe>

>> C.2.3.4, C.2.3.5  (our issue 14-19)
>>
>> I'm not sure if the 'condition' in the formal signature includes 
>> domainofapplication elements. If not, this needs to be amended.  
>> Also, to be consistent with, say, int, the signature
>>
>> (domainofapplication, function) -> anything 
>> [or perhaps (... -> codomain(function)), to be more specific] should 
>> be allowed with the meaning of the supremum of the function over the 
>> specified set.
>>
>> In the last example, the interval should render as a closed interval.
>>
>    [JSD] fixed as per the discussion of domainofapp at the beginning of
>    this note and in earlier notes to be  (domainofapp,function) ->
>    algebraic.   We chose algebraic over anything as we considered
>    posets over relations as being outside of k-14 - the nominal
>    audience - and so best left to extensions. 

Actually, I learned that

      max(true,false)=true

in highschool, and thus, for example, even for K-14ers,
 
      max(domofapp(truthvalues),<not/>) = <true/>

At first glance my above diatribe thus applies here, too.

Still, I can't come up with a large set of K-14 examples where this 
would really make sense, except in this one single, admittedly 
contrived, example.

> C.2.4.2  our issue (14-24)
>
>> An n-ary version of neq makes sense too, returning true if none of 
>> the arguments are equal. this paragraph should be more like the ones 
>> for eq, lt, gt, leq, and geq then.
>>
>    [JSD]  This was left as binary as it was felt that there were too
>    many choices for what n-ary might mean. 

I could only come up with one consistent one, but if you found more, 
then your resolution is fine with me.

>> C.2.5.2   our issue 14-27
>>
>> I remarked in my previous posting that this should perhaps be defined 
>> more like partialdiff.
>>
>    [JSD]  We left this as univariate.  We were not want to get into the
>    possible interpretations and conventions that a multivariate form of
>    this would mean.  As it stands even fairly introductory users will
>    have not confusion over which to use.  Also, given that apply's of
>    csymbols  can use bvar, there is nothing preventing us from
>    experimenting  with various possibilities and at some point moving a
>    successful model more formally into the spec at some point in the
>    future. 

I admit that I don't recall ever having had any doubt, at least in the 
K-14 context, what the version corresponding to partialdiff would mean, 
since I was only ever taught a single interpretation during that time 
(and admittedly no other interpretation since).

Still, I recognize that this change might be a bit radical for just a 
second edition.
Received on Friday, 11 July 2003 08:18:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:55 GMT