| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788.1, Voting on M004.02 is closed. The motion PASSES. Yes: 34; No: 6; Abstain: 1; Number of Voting Members: 43; Needed for quorum: 29. Below is a digest of “NO” votes and comments, followed by Nathalie’s announcement. George Corliss P1788.1 Voting Tabulator > From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx> > Subject: Re: Voting period begins, until June 21, for Motion P1788.1/M004.02 --- NO > Date: June 1, 2016 at 3:18:43 PM CDT > To: <stds-1788@xxxxxxxxxxxxxxxxx> > > I vote NO. > > I would vote YES if either > a) the standard P1788 didn't exist and P1788.1 was the first interval standard > or > b) P1788.1 were designed so that it became a flavor of P1788 . > > Interval litertal is the only topic where P1788.1 doesn't conform to common P1788 requirements for all flavors. > > -Dima From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> Subject: Re: Motion P1788.1/M004.02, YES Date: June 10, 2016 at 1:19:53 PM CDT To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx> I vote YES. However, I hope we take Dima's reservations seriously and do our best to support his efforts to produce reference implementations. Baker From: Sergei Zhilin <szhilin@xxxxxxxxx> Subject: Motion P1788.1/M004.02: No Date: June 15, 2016 at 8:02:39 PM CDT To: <STDS-1788@xxxxxxxxxxxxxxxxx> I vote NO on motion 4.02 for the reasons described in Dima Nadezhin's voting letter. From: Ulrich Kulisch <ulrich.kulisch@xxxxxxx> Subject: Re: PLEASE VOTE: Motion P1788.1/M004.02 Date: June 17, 2016 at 1:56:26 AM CDT To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx> My vote on this motiion is NO. I would vote YES if interval arithmetic would just be defined as calculus for connected sets of real numbers. Here -oo and +oo are only used for the description of unbounded real intervals. They are, however, not elements of these intervals This leads to a calculus that is free of exceptions. Defining interval arithmetic on the extended reals is a mistake. It unnecessarily pulls IEEE 754 and other exceptions into interval arithmetic and complicates it unnecessarily. It is the source of much confusion. Ulrich Kulisch > From: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Re: Voting period begins, until June 21, for Motion P1788.1/M004.02 > Date: June 2, 2016 at 8:00:19 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > I vote NO (see below). > > On 2016-06-01 19:00:27 +0200, Nathalie Revol wrote: >> As we want to have a simplified version of IEEE 1788-2015, I suggest >> that we vote on the text of Motion M004.02 (see attached file), >> which is Motion M004.01 amended as follows: >> (cf. mail by Ned Nedialkov, May 24) >> —— >> I suggest in 6.6.2 in the first item to add the text “of the same radix (10 or 16)”. The first sentence >> would read then >> >> "A string [l,u] where l and u are optional number literals of the same radix (10 or 16) with l ≤ u, l < +∞ and u > −∞, see 4.2. “ >> —— > > I think that this is dangerous. Strings may not necessarily be > generated from the implementation, but often comes from the outside. > And there, an interval literal with l and u of different radices may > occur. The problem is that if it is considered as invalid in P1788.1, > then the conversion by textToInterval will give Empty, which may be > surprising. > > Note also that there's something missing in the text in §6.6.2: > "These number literals must be of the same Its bare value is the > ^^^^^^^^ > mathematical interval" > > Or "These number literals must be of the same" should have been > removed. From: Michel Hack <mhack@xxxxxxx> Subject: Re: Voting period begins, until June 21, for Motion P1788.1/M004.02 Date: June 19, 2016 at 8:06:37 AM CDT To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> On Thu, 2 Jun 2016 15:00:19 +0200, Vincent Lefèvre noted an editorial issue in 6.6.2 (line 9 of page 21): > Or "These number literals must be of the same" should have been > removed. This is what I suggest be done. Now, Vincent objects to the same-radix requirement. Normally I would object too, but I gave in on my proposal in the 754-2008 work group to specify cross-radix comparisons as optional, but required to be correct if provided. Instead, 754-2008 discourages cross-radix comparisons, and since 1788.1 derives its numerical basis from 754-2008, I agree with the restriction that avoids the need for correct cross-radix comparisons. Michel. ---Sent: 2016-06-19 13:35:30 UTC From: Michel Hack <mhack@xxxxxxx> Subject: Motion P1788.1/M004.02: YES Date: June 19, 2016 at 8:35:38 AM CDT To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> I vote YES on the text of "6. Level 2 description", but with two editorial comments: Page 21 Line 9 (in 6.6.2): Delete "These number literals must be of the same" (This was an incomplete sentence; the substantive statement is on the preceding line 8.) Page 22 Line 7 (in 6.7.6): add "as defined by 754-2008" after "closest to x". (Unqualified "closest to x" could me misleading when x is finite but out of b64 range, as the largest representable magnitude Max could be seen as closer than infinity for any finite x, yet 2008-754 specifies that the rounding threshold for nearest(x)=Inf is Max+ulp/2.) Michel. ---Sent: 2016-06-19 13:48:25 UTC From: "Nedialkov, Ned" <nedialk@xxxxxxxxxxx> Subject: Re: Motion P1788.1/M004.02: YES Date: June 20, 2016 at 10:19:40 AM CDT To: Michel Hack <mhack@xxxxxxx> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> Hi Michael, Good observations. I have incorporated them. Not sure if I have to circulate the text again. Regards, Ned From: Evgenija Popova <epopova@xxxxxxxxxx> Subject: Motion P1788.1/M004.02: NO Date: June 20, 2016 at 10:40:57 AM CDT To: <stds-1788@xxxxxxxxxxxxxxxxx> Reply-To: <epopova@xxxxxxxxxx> I vote NO. In my opinion producing two non-conforming interval standards will be a bad message for the end-users. I would vote YES if P1788.1 was in conformance (flavor) to IEEE Std 1788-2015. Evgenija Popova From: Ian McIntosh <ianm@xxxxxxxxxx> Subject: Re: Motion P1788.1/M004.02: NO Date: June 20, 2016 at 12:37:57 PM CDT To: <stds-1788@xxxxxxxxxxxxxxxxx> I agree. The simplified standard should be a flavour of the full standard. I do appreciate all the work that's gone into it and hope this can be resolved. - Ian McIntosh IBM Canada Lab Compiler Back End Support and Development From: "Nedialkov, Ned" <nedialk@xxxxxxxxxxx> Subject: Re: Motion P1788.1/M004.02: NO Date: June 20, 2016 at 4:52:31 PM CDT To: Ian McIntosh <ianm@xxxxxxxxxx> Cc: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx> > On Jun 20, 2016, at 13:37, Ian McIntosh <ianm@xxxxxxxxxx> wrote: > > I agree. The simplified standard should be a flavour of the full standard. I do appreciate all the work that's gone into it and hope this can be resolved. > My view is keep it simple and functional and get it into “production” as soon as possible. I don’t believe that e.g. rational literals will make a big difference in practice. There might be some applications of them in academia, but we really want to get into industrial applications. P1788.1 does not contradict P1788. The following quotes are from the abstract: "This standard is a simplified version and a subset of the IEEE Std 1788TM-2015 for Interval Arithmetic and includes those operations and features of the latter that in the the editors’ view are most commonly used in practice. “ "A program built on top of an implementation of IEEE P1788.1 should compile and run, and give identical output within round off, using an implementation of IEEE Std 1788TM-2015, or any superset of the former.” "Compared to IEEE Std 1788TM-2015, this standard aims to be minimalistic, yet to cover much of the functionality needed for interval computations. As such, it is more accessible and will be much easier to implement, and thus will speed up production of implementations. “ Ned From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx> Subject: Motion P1788.1/M004.02 Date: June 21, 2016 at 9:26:53 AM CDT To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> I vote YES. That said, I reiterate what I already said in previous email: The standard should refrain from telling that a "call fails" when the standard also tells that the call succeeds in returning a perfectly and completely defined result. Also, I agree with Vincent: The restriction on the radix of the text-to-interval function seems gratuitous to me. Best regards, Guillaume > Begin forwarded message: > > From: Nathalie Revol <Nathalie.Revol@xxxxxxxxxxx> > Subject: Voting period begins, until June 21, for Motion P1788.1/M004.02 > Date: June 1, 2016 at 12:00:27 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Nedialkov, Ned" <nedialk@xxxxxxxxxxx> > Cc: Nathalie Revol <Nathalie.Revol@xxxxxxxxxxx> > > > Dear Colleagues > > voting period for Motion M004.01 begins today (I implicitely extended the discussion > period, as discussions were most lively last week). It ends on June 21. > > As we want to have a simplified version of IEEE 1788-2015, I suggest that we vote > on the text of Motion M004.02 (see attached file), which is Motion M004.01 amended > as follows: > (cf. mail by Ned Nedialkov, May 24) > —— > I suggest in 6.6.2 in the first item to add the text “of the same radix (10 or 16)”. The first sentence > would read then > > "A string [l,u] where l and u are optional number literals of the same radix (10 or 16) with l ≤ u, l < +∞ and u > −∞, see 4.2. “ > —— > > If you are no more on the voting list and want to be reinstantiated, please send me a message. > > Best regards > Nathalie Revol >
Attachment:
M004.02-Level2.pdf
Description: M004.02-Level2.pdf