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

Andreas,

On these two outstanding issues, we have decided to proceed as follows:

1.   Signature in appendix C so that pieces and other can have other 
than algebraic values:

    We are adding the signatures   (boolean, any) -> any , for piece, 
    and (any) -> any  for otherwise,  in addition to the already
    existing "algebraic" signatures.   The algebraic case corresponds
    shows the usual expected case, while second signature shows it can
    be relaxed.

2.   signatures for max( domainofapp , boolean )

 We still we feel  that the notion of  a "total order" on the booleans 
is just enough outside the usual expectations for max/min that we would 
like to see such uses flagged  with the use of a definitionURL pointing 
to an explanation of the convention being followed.

Keeping in mind that this revision of the spec will next go out for 
review as a Proposed Recommendation, during which time it is still 
possible to respond to small tweaks, we will now move on to this next
stage.

Thanks once again, for all the input.

Stan Devitt
Math Working Group.

Andreas Strotmann wrote:

>
> 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 Monday, 14 July 2003 18:17:54 UTC