Re: P1788: Motion 44 NO votes
P1788
I thank you, George, for providing your customary summary. Here are my responses to the NO votes, and at the bottom of this email the proposed revisions.
1.
Guillaume Melquiond, Jun 2.
> 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?
That was just bad wording, thanks for pointing it out.
> 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.
My view has been that at Level 1 a function, given inputs outside its domain, "has no value". E.g. real square root of -1, or 0/0, or text2interval("I'm garbage") have no value at Level 1. This matches the standard set-theory definition of a function. At Level 1 the questions "does it return?" or "does it never terminate" are meaningless. This has been discussed but maybe is not clearly enough stated in the Level 1 text.
At Level 2, every operation always returns a value, and Level 1's "no value" *usually* turns into NaN, or NaI; but not always -- e.g. midpoint & related functions.
2.
Christian Keil, Jun 2 about interval literals.
> The changed sentence references "Rules" in the Level 2 description
> that "may optionally be followed".
I hope the revised text of 9.6.1, 9.6.8 makes clear "optional" applies to Level 1 only.
3.
Bill Walster's query, May 30. This doesn't point out errors but does raise questions about our syntax for literals.
> 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.
Sun has intervals embedded in the language, which means that the mapping between Sun syntax/semantics and 1788 functions is rather crucial. In particular interval literals are part of the language. So you don't *need* text2interval() since where 1788 requires
interval xx = text2interval("[0.1,0.2]")
Sun just lets you write
interval xx = [0.1,0.2]
and the language knows this means "an enclosure of the exact mathematical interval [0.1,0.2]".
I wasn't so clear about the next bit. From the cited section 2.9.2 of the Sun Fortran 95 Interval Programming Reference, if the programmer wants "the interval whose endpoints are the internal representations of 0.1 and 0.2" then this can be done by
real a=0.1, b=0.2
interval yy = interval(a,b)
is that right? So possibly neither of xx and yy contains the other. And I think
interval yy = interval(0.1,0.2)
has the same effect? I could not quite make out what code example 2-18 aims to show.
In fact 2.9.2 doesn't seem the relevant place. I should look at 2.10.2.1 "External Representations" which seems to say (where the items at the left are literals, and e.g. [X] means the character '[' followed by a number literal followed by the character ']')
> There are three displayable forms of an external interval:
> (a) [Xinf, Xsup] represents the mathematical interval [Xinf, Xsup]
> (b) [X] represents the degenerate mathematical interval [X, X]
> (c) X represents the non-degenerate mathematical interval [x] + [-1,+1]uld
> (unit in the last digit).
> This form is the single-number representation, in which the last
> decimal digit is used to construct an interval (see the Y edit
> descriptor). In this form, trailing zeros are significant. Thus
> 0.10 represents interval [0.09, 0.11], 100E-1 represents interval
> [9.9, 10.1], and 0.10000000 represents the interval [0.099999999,
> 0.100000001].
(a) is a 1788 literal, e.g. the string
[0.1,0.2]
(b) is proposed as an addition to 1788 syntax, e.g. the string
[0.1]
equivalent to
[0.1,0.1]
(c) is not supported and has not been suggested. Does anyone speak up for it? At present we have the form
0.10?1 equivalent to Sun's 0.10 representing [0.09, 0.11]
0.10000000?1 equivalent to Sun's 0.10000000 representing
[0.099999999, 0.100000001]
etc. This notation is from the Vienna Proposal and is only marginally more complicated.
In summary:
- P1788 interval literals are close but not identical to Sun Fortran's "external representations".
- From a quick read, it seems Sun's interval types and operations on them, *structurally*, are pretty well identical with a P1788 "754-conforming implementation" with a binary radix.
- In detail, however, the Sun Fortran interval operations cannot be conforming because they are based on the cset model. E.g. the tightest enclosure of [0]/[0] is Empty in 1788 arithmetic and Entire in Sun arithmetic. The cset result always includes the 1788 result, so enclosure is not a problem, but tightness is a problem.
- And of course Sun doesn't have decorations.
=================
On 3 Jun 2013, at 23:20, Corliss, George wrote:
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
==========Proposed changed text=========
I've shortened 9.6.1 which now says
> An interval literal is a text string that denotes an interval, termed its value. Level 1, which is mainly for human communication, merely assumes some agreed rules on the form and meaning of interval literals exist. In this document the Level 2 specification, see §11.11.1, is used where relevant. [Example. This includes the inf-sup form [1.234e5,Inf]; the mid-rad form <3.1416+-0.00001>; or the named interval constant Entire.]
I've shortened 9.6.8 (now 9.6.9) which now says
> An interval constructor by definition is an operation that creates a bare or decorated interval from non-interval data. The following bare interval constructors shall be provided.
> The operation nums2interval(l,u), takes extended-real values l and u. If (see §9.2) the conditions l <= u, l < +oo and u > -oo hold, it returns the nonempty interval [l,u] = {x ∈ R | l <= x <= u}. Otherwise it has no value.
> The operation text2interval(s) takes a text string s. If s is an interval literal, see §9.6.1,11.11.1, it returns the interval denoted by s. Otherwise it has no value.
In particular the notion of "succeed" or "fail" is now at Level 2 only & has been completely removed from Level 1. I hope this works.
Baker notes 9.6.8 refers to clause 13 (I/O). That is obsolete & has been replaced by refs to 9.6.1 and 11.11.1.
I changed the start of 11.11.1 (Level 2 interval literals) so as not to repeat 9.6.1. It now says
> This subclause defines the Level 2 syntax and semantics for interval literals, see §9.6.1. A number literal (within this subclause) means a string that may be part of an interval literal and denotes an extended-real number, termed its value.
Unless someone objects I propose, in 11.11.1, to
- Keep all the current features (4 forms of number literal, 3 forms of interval).
- Add the single-point interval form e.g. [3] for [3,3], as in Sun Fortran.
- Drop the idea of implementation-defined named constants such as pi.
In 11.11.8 (Level 2 versions of nums2interval & text2interval) I've not changed anything. It all looked necessary to me; but some people think it is all OTT. If you do, let us debate it.
Baker mentions §13 on I/O. Till I re-looked at it today, I thought it had a lot of stuff that interval literals 11.11.1 & constructors 11.11.8 have made redundant. But I don't think it can be shortened much. I am studying it.