| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788,
Motion M0061.02 Revised Flavors Text PASSES:
Yes - 34; No - 0; Needed for quorum - 29
Baker’s announcement of the voting period is below.
A digest of comments during the voting period is appended below.
George Corliss,
P1788 Voting Tabulator
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Subject: Motion P1788/M0061:REvisedFlavorsText -- voting period begins
> Date: February 7, 2014 at 8:24:51 AM CST
> To: John Pryce <j.d.pryce@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> 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
Begin forwarded message:
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0061:REvisedFlavorsText -- YES
> Date: February 15, 2014 at 6:47:23 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on the motion is YES.
>
> There are however some things I'd like to note:
>
> 1) The revised text lists the com decoration to be *required* for a flavor
> in several places, while the decoration clause (8) says a flavor *may*
> provide it and only *requires* it from all flavors of an implementation
> if the implementation provides more than one flavor. Either the current
> text or the decoration clause (8) should be changed to be consistent.
>
> 2) Subitem (v) of the core specification seems to refer to §7.4 and §7.5,
> but doesn't list them explicitly. Adding these references would clarify
> the structure further.
>
> 3) While not opposing, I'm not sure about the scope of §7.4.3. If the
> flavor is a standard flavor it is defined in a later section of the
> standard and lists whatever function it requires. If it is a non-standard
> flavor, it is presumably a one-implementation-flavor provided in one
> implementation, which limits the usability of functions that are
> "required in each implementation of that flavor". In short: I'm not sure
> if this is a part of the core specification or rather an option for new
> flavors to be submitted for inclusion into the standard?
>
>
> Cheers,
>
> Christian
Begin forwarded message:
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: PLEASE VOTE P1788/M0061:RevisedFlavorsText
> Date: February 26, 2014 at 2:04:53 AM CST
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Dear 1788 members,
>
> I vote YES on motion 61 Flavors Text.
>
> However, I have a comment on the wording of one paragraph that we should
> revise when we vote on the final text. On the first page the current
> text says:
> " Flavor is a property of program execution context, not of an
> individual interval. Therefore, just one flavor shall be in force at any
> point of execution. It is recommended that at the language level, the
> flavor should be constant over a procedure/function or a compilation
> unit."
>
> The above text is valid in general for an execution context that
> computes a result. However, if a library procedure/function is written
> to convert between flavors then it cannot follow the restrictive
> condition of "one flavor shall be in force". The standard must allow for
> such conversion routines to deal with multiple flavors simultaneously.
>
> Thanks and best regards
>
> --
> Dr. Hossam A. H. Fahmy
> Associate Professor
> Electronics and Communications Engineering
> Cairo University
> Egypt
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motion P1788/M0061:REvisedFlavorsText -- YES
> Date: February 28, 2014 at 8:35:04 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on M0061. But I have some comments for §7.5.3:
>
> §7.5.3, 1st paragraph: "For each flavor-specific operation, the flavor
> shall give a rule to determine when an implementation shall provide a
> T-version." but what's the point of defining a Level 1 flavor-specific
> operation but not provide it at Level 2? In any case, I don't think
> that this sentence is useful.
>
> §7.5.3, 3rd paragraph: in "a /special value/ of the output means a
> flavor-defined datum that either has diagnostic value, or is regarded
> as useful in practice", the part "or is regarded as useful in practice"
> doesn't seem to bring any information as it is too vague. And isn't a
> special value related to some particular operation and inputs? I mean
> that in mid(Entire) = 0, 0 is regarded as a special value, but in
> mid([-1,1]) = 0, 0 isn't a special value. The specification doesn't
> make this clear. I suggest that the notion of special value be removed;
> it can be replaced below by "flavor-defined value", and the reason for
> such a rule can be explained with an example, like the one about mid().
> The specialness of the value in this context just comes from the fact
> that it isn't defined at Level 1.
>
> §7.5.3, last line "(d) If Y is boolean, phi_T returns Y.": Shouldn't
> some flavor-, implementation- or language-specific behavior be allowed
> in case it is too hard to determine the boolean (i.e. the "not found"
> case)? Implementations or languages that have an "Indeterminate" or
> (equivalently) "{True,False}" value in addition to "True" and "False"
> could use it.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motion M0061.02 : YES
> Date: February 28, 2014 at 2:19:18 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion RevisedFlavorsText.
>
> A few comments though:
>
> As Hossam Fahmy already mentioned, the overview is a bit too restrictive. For instance, it precludes a function to receive and return intervals corresponding to a given flavor, yet internally use a flavor better suited for its computations.
>
> The last paragraph of 7.5.4 is a bit restrictive too. It might well happen that two different implementations are just incomparable. I am thinking in particular of elementary functions; which one of two implementations is the most accurate presumably depends on the input domain (values close to zero, large values, etc) due to their having different argument reduction.
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion M0061.02 : YES
> Date: February 28, 2014 at 8:53:26 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2014-02-28 09:19:18 +0100, Guillaume Melquiond wrote:
>> The last paragraph of 7.5.4 is a bit restrictive too. It might well happen
>> that two different implementations are just incomparable. I am thinking in
>> particular of elementary functions; which one of two implementations is the
>> most accurate presumably depends on the input domain (values close to zero,
>> large values, etc) due to their having different argument reduction.
>
> I think that linear ordering may be useful for the end user, and
> the current "should" is OK. But IMHO, the ordering should just be
> informative, and not necessarily linear: accuracy mode 1 > accuracy
> mode 2 when in general f1(X) in included in f2(X), without a guarantee
> that this is always the case. The idea is to inform the user that he
> will generally get more accurate results by choosing mode 1 instead of
> mode 2. The only guaratee is that for inf-sup types (when the hull is
> unique), the tightest mode gives the most accurate results.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Subject: RE: Motion M0061.02 : YES
> Date: February 28, 2014 at 9:32:35 AM CST
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> True, a good example is complex numbers, we can use circles or boxes to describe uncertainty, and depending on what we use, we get different results which are not always compatible.
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail