P1788: Motion 44 NO votes
P1788,
Below are the four NO votes and discussions that followed for Motion 44.
George Corliss
P1788 Voting Tabulator
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motion 44.01: NO
> Date: June 2, 2013 10:25:28 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 44 Constructors.
>
> Christian Keil raises a good point: An "optionally followed rule" feels like a recipe for disaster. So this part of the sentence should be dropped. And if the rules are really meant to be optional, all the occurrences of "shall" in 11.11.1 should be changed to "should".
>
> I have another issue with 9.6.8. It says that a constructor that fails "returns no value", while two lines above, it says that it "returns the set ...". Which is it? Moreover, I understand "returns no value" as meaning that it does not return at all, which basically requires that it either throws or never terminates. I don't think this was the intent of the text, so this part should just be dropped. To summarize, I would have voted yes if the paragraph had been roughly structured as "nums2interval takes l and u; if l <= u, the operation succeeds and returns [l,u], otherwise it fails".
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Subject: Re: Motion 44.01 PLEASE VOTE - I vote No
> Date: May 30, 2013 6:29:08 PM CDT
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> George,
>
> I am unable to send the following to the P1788 email address <stds-1788@xxxxxxxxxxxxxxxxx> that I have. So, will you please forward it to the alias for me?
>
> Thanks in advance,
>
> Bill
>
> =====email to P1788=========
>
> I am unable (perhaps it is me) to determine if the scheme implemented in Sun's implementation of string to interval and interval to string conversion will be standard conforming or not. The Sun Fortran 95 implementation explicitly deals with strings as infinitely precise decimal numbers versus strings in which interval width is determined by the last decimal digit in a string.
>
> If the Sun Fortran implementation is standard conforming, or if the draft can be updated to allow the sun string conversion implementation to be standard conforming, I will change my vote to Yes.
>
> See Section 2.9.2 starting on page 98 of Sun's Interval Arithmetic Programming Reference.
>
> Cheers,
>
> Bill
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>
> Subject: Re: Fwd: Motion 44.01 PLEASE VOTE - I vote No
> Date: May 31, 2013 4:27:31 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: "<stds-1788@xxxxxxxxxxxxxxxxx>" <STDS-1788@xxxxxxxxxxxxxxxxx>, "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> Bill, P-1788,
>
> Indeed, 9.6.8 does not specify exactly to WHAT interval the
> string is converted, but refers to clause 13. It is made
> specific in 13.2 (specification for "text2interval"), and we
> haven't formally processed the actual text of 13.2 yet. My
> reading of 13.2 is that, in general, the only requirement
> is that text2interval return an enclosure for the human-understood
> number or interval represented by "s", but that for an interval
> type based on the 754 format, it should return the tightest
> such enclosure. My reading of this is that, if the Sun F95
> interval implementation does not claim to be based on IEEE 754,
> it is conforming as long as it returns an interval containing
> the result, but, if it claims to be a 754-conforming type,
> it must return the tightest such interval.
>
> For example,
> for a non-754 conforming type, text2interval([.5,.5]) could store
> the binary representation (or other internal representation) of [.5,.5]
> or it could store its internal representation corresponding
> to [.4,.6]. For a 754-conforming type, text2interval([.5,.5]) must return
> an internal representation of the point interval [.5,.5], but
> text2interval([.1,.1]) would need to return a non-zero-width
> interval that must be the narrowest such interval containing [.1,.1].
>
> Please correct me if I am wrong.
>
> Shall we put some non-normative examples in clause 13?
>
> Hopefully we can process clause 13 soon.
>
> A question: Is text2interval([.1,.1]) unique?
> (This would be important for reproducibility.)
>
> Best regards,
>
> Baker
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Subject: Re: Fwd: Motion 44.01 PLEASE VOTE - I vote No
> Date: May 31, 2013 2:25:08 PM CDT
> To: <rbk@xxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, "<stds-1788@xxxxxxxxxxxxxxxxx>" <STDS-1788@xxxxxxxxxxxxxxxxx>
>
>
>
> Thanks, Baker.
>
> Well, the interval standard needs to give users a way to specify exactly to WHAT interval a given string is converted.
>
> This is exactly what is done in Sun's Fortran string input conversion and interval output conversion. Thus, it is possible to specify that the interval [0.1, 0.1] is to be interpreted as the infinite precision real number equal to 1/10, or as the exact real interval [0,2/10].
>
> Other features include the ability to enter 0.1000 and to have this automatically converted to [0.0999, 0.1001].
>
> It is these kinds of details that contribute to ease of use and reliability than I believe should be permitted by the standard. This is why I also believe in general that the standard should not be prescriptive, but rather should be permissive, provided only that containment is never violated, both on conversion from and to strings, which includes I/O.
>
> By your qustion "Is text2interval([.1,.1]) unique? do you mean the result of text2interval (.), then I believe the answer should be NO and there needs to be a way to specify more details about the conversion process, as described above and in the Fortran Reference Manual, which I believe people might benefit from reading in its entirety. The same goes for the conversion interval2text(.).
>
> See: <http://docs.oracle.com/cd/E19059-01/stud.10/819-0503/819-0503.pdf>
>
> Cheers,
>
> Bill
>
>
>
> On 5/31/13 2:27 AM, Ralph Baker Kearfott wrote:
>> Bill, P-1788,
>>
>> Indeed, 9.6.8 does not specify exactly to WHAT interval the
>> string is converted, but refers to clause 13. It is made
. . .
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion 44.01 PLEASE VOTE - I vote No
> Date: June 1, 2013 11:28:35 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Bill
>
> On 31 May 2013, at 03:14, Corliss, George wrote:
> On May 30, 2013 6:29:08 PM CDT, Bill Walster wrote:
>>
>> I am unable (perhaps it is me) to determine if the scheme implemented in Sun's implementation of string to interval and interval to string conversion will be standard conforming or not. The Sun Fortran 95 implementation explicitly deals with strings as infinitely precise decimal numbers versus strings in which interval width is determined by the last decimal digit in a string.
>>
>> If the Sun Fortran implementation is standard conforming, or if the draft can be updated to allow the sun string conversion implementation to be standard conforming, I will change my vote to Yes.
>
> I have much respect for the Sun Fortran implementation and we could probably learn from it about this issue. Could you just remind us of the details of its scheme that you mention above? And also how much it overlaps with the scheme in the Vienna proposal, which has a similar feature of "infinitely precise decimal numbers versus ... interval width determined by the last decimal digit"?
>
> John Pryce
Begin forwarded message:
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0044:Constructors -- NO
> Date: June 2, 2013 9:27:34 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on the Motion is NO.
>
> As I read it there is an inconsistency in the changed sentence
> that needs to be addressed for me to change my vote to yes.
> The changed sentence references "Rules" in the Level 2 description
> that "may optionally be followed".
> While rules being optionally followed already sound strange to me
> in the first place, this clause thus sounds to me like the statements
> in 11.11.1 may optionally be followed, while the referenced subclause
> itself gives rules on literals that "shall be supported" and are thus
> mandatory and not optional (see the paragraphs before the lists of
> number literals and interval literals in 11.11.1). This contradiction
> ---if I'm not misreading things---has to be resolved.
> My preference would be to require the literal's support or at least
> require some subset. In the current clause this could be remedied by
> simply stating "Rules for the string t accepted at an implementation
> level are given in the Level 2 Subclause 11.11.1 on interval
> literals.", dropping the part referencing the rules as optional. The
> exact situation of the literals should then be addressed in 11.11.1.
>
> Cheers,
>
> Christian
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0044:Constructors -- NO
> Date: June 3, 2013 7:10:44 AM CDT
> To: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> P1788
>
> On 2 Jun 2013, at 15:27, Christian Keil wrote:
>> My vote on the Motion is NO.
>>
>> As I read it there is an inconsistency in the changed sentence
>> that needs to be addressed for me to change my vote to yes.
>> The changed sentence references "Rules" in the Level 2 description
>> that "may optionally be followed".
>
> The intent is that at Level 2 you shall follow the given syntax but at Level 1 you can do what you like. I changed the relevant text already in response to similar comments (from Michel Hack?) so it now reads
>
>> 9.6.1. Interval literals.
>> An implementation shall provide denotations of exact interval values by text strings. These are called interval literals. Level 1, which is mainly for human communication, makes no requirements on the form of literals. This document uses the Level 2 syntax, specified in §11.11.1. [Example. This includes the inf-sup form [1.234e5,Inf]; the mid-rad form <3.1416+-0.00001>; or the named interval constant Entire.]
>> An invalid denotation has no value at Level 1.
>
> Is there still a problem?
>
> John Pryce
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motion 44.01: NO
> Date: June 2, 2013 10:25:28 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 44 Constructors.
>
> Christian Keil raises a good point: An "optionally followed rule" feels like a recipe for disaster. So this part of the sentence should be dropped. And if the rules are really meant to be optional, all the occurrences of "shall" in 11.11.1 should be changed to "should".
>
> I have another issue with 9.6.8. It says that a constructor that fails "returns no value", while two lines above, it says that it "returns the set ...". Which is it? Moreover, I understand "returns no value" as meaning that it does not return at all, which basically requires that it either throws or never terminates. I don't think this was the intent of the text, so this part should just be dropped. To summarize, I would have voted yes if the paragraph had been roughly structured as "nums2interval takes l and u; if l <= u, the operation succeeds and returns [l,u], otherwise it fails".
>
> Best regards,
>
> Guillaume