RE: Motion P1788/M0061:REvisedFlavorsText -- voting period begins
I vote For
-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Ralph Baker Kearfott
Sent: Friday, February 07, 2014 7:25 AM
To: John Pryce; stds-1788
Subject: 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
---------------------------------------------------------------