Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Motion P1788/M0061:REvisedFlavorsText -- voting period begins

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

Attachment: 20140203Flavors.pdf
Description: Adobe PDF document