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