- From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- Date: Tue, 15 Jul 2003 13:32:36 +0200
- To: Stan Devitt <jsdevitt@stratumtek.com>
- CC: "www-math@w3.org" <www-math@w3.org>
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&In-Reply-To=<3EBBC21E.9080803@rrz.uni-koeln.de>&References=<3EBBC21E.9080803@rrz.uni-koeln.de>>) >>>> >>>> *Date:* Fri, May 09 2003 >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> <mailto:www-math@w3.org?Subject=Re:%20errata%20and%20comments,%20chapter%20C%20%28first%20installment%29&In-Reply-To=<3EBBC21E.9080803@rrz.uni-koeln.de>&References=<3EBBC21E.9080803@rrz.uni-koeln.de>>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