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