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

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&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 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
*