| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
YES George Corliss On Feb 7, 2014, at 8:24 AM, Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> wrote: > P-1788: > > Voting on this motion herewith begins. The rules for > standard text motions apply. > > Voting will continue until after Friday, February 28, 2014. > > Juergen: Please update the on-line list of motions with > this information and the updated document. > > Best regards, > > Baker > > On 02/03/2014 09:01 AM, John Pryce wrote: >> P1788 >> >> Here is a new draft of Clause 7 "Flavors". I think the ideas > are now made firm. There may be minor changes because of poor > wording - please read with care, and complain about any > obscurities. But I believe this text is ready to proceed to the > vote. >> >> The main changes are: >> >> 1. A thorough revision of §7.5.3 "Level 2 operations". Following Vladik's >> support for my thesis that "uncertainty is essential", the possibility >> that an implementation may be unable to decide certain facts, because of >> algorithmic constraints, is made an inherent feature of Level 2 in any >> flavor. >> >> For example the description (7.5.3 item 3(b)) of how the T-version phi_T of >> an operation phi with decorated-interval result is handled now says >> >>> If [the Level 1 result is found to exist and] is a decorated interval y_dy there are >>> three cases. >>> - If phi is an arithmetic operation, and [the input box] is a decorated >>> common input (this implies dy=com, see §7.4.2), and a common T-interval >>> z containing y is found, then phi_T returns such a z with the decoration >>> com. >>> - Otherwise, if a T-interval z containing y is found (in particular if >>> Entire exists in the flavor and is a T-interval), then phi_T returns >>> such a z with a flavor-defined decoration. >>> - Otherwise, no such z is found. Then phi_T signals the IntvlOverflow >>> exception and the returned result, if any, is flavor-defined. >> >> Here "is found" is defined to mean that the implementation is able to compute >> a value, or determine whether a fact is true. >> >> In the first of the 3 cases above, I've kept the requirement that the returned >> decoration is "com" -- not a possibly weaker decoration, as suggested by Michel. >> This is because it seems to me all the bases have been covered: >> - The input *is* a decorated common input box, meaning its components are common >> intervals decorated "com". I said "is", not "is found to be", because I can't >> conceive a flavor, type or implementation, where it is difficult at run time to >> decide if a given interval is common or not. Is that reasonable? >> - The common z containing y "is found" by the implementation. So at this point all >> uncertainty has disappeared, and there is no reason to return a weaker decoration. >> >> The terms "decorated common evaluation" and "decorated common input" have been made >> Level 1 (not Level 2) notions, put in 7.4.2. The subsubsection after 7.4.3 that used >> to define them has been removed. >> >> 2. I have changed the exceptions "IntvConstructorFails" and "IntvConstructorUnsure" to >> "UndefinedOperation" and "PossiblyUndefinedOperation" throughout the text, for the >> reasons I stated before. >> > > > -- > > --------------------------------------------------------------- > R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax) > (337) 482-5270 (work) (337) 993-1827 (home) > URL: http://interval.louisiana.edu/kearfott.html > Department of Mathematics, University of Louisiana at Lafayette > (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street) > Box 4-1010, Lafayette, LA 70504-1010, USA > --------------------------------------------------------------- > <20140203Flavors.pdf>
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail