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

Stan,

thanks, that answers my questions.

 -- Andreas

Stan Devitt wrote:

> 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 Tuesday, 15 July 2003 07:32:53 UTC