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

Motion 61 Voting to begin after February 5 Re: Re-revised Clause 7 "Flavors", hopefully ready for vote

P-1788:

First, I thank John on behalf of P-1788.

As previously announced,  we will start voting on this
motion after February 5.  If anyone has any
additional significant changes  to this motion,
please post them immediately.

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.

There are various issues of conformance and documentation that I would also like you to check and ponder. E.g. at the start of 7.5.3:
   "the flavor SHALL give a rule ..." about T-versions of flavor-specific operations;
   "The flavor SHOULD make recommendations or requirements" about the number formats
   use for numeric results of operations.

Should these be there at all? Should the "shall" become "should" or vice versa? Are there other places where the standard should require a flavor to specify things, but currently doesn't? I know these are "meta-questions". I know flavors are in many ways a nuisance. I know it seems 1788 won't contain any Kaucher flavor for the present.

But we have flavors, and we should get them right. And I remain convinced that flavors will in the future turn out to have been worth the effort of inventing them.

Regards

John Pryce




--

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