Motion M0024.03 Rounding Mode as Operations PASSES
P1788,
Motion M0024.03 PASSES
Yes: 31
No: 16
Required for quorum: 37
A digest of comments is included below.
Reminder: Motions 26 and 27 are open for voting. PLEASE VOTE.
Currently, six people have voted on each motion.
George Corliss,
P1788 Voting Tabulator
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Motion P1788/M0024.03:RoundedOperations: Voting period begins
> Date: July 6, 2011 7:01:28 AM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxx>, <rbk@xxxxxxxxxxxxx>
>
> P-1788:
>
> The discussion period for Motion 24 version 3 has ended, and
> the voting period herewith begins. Voting will continue until
> the end of Wednesday July 27, 2011. The rules for voting on position
> papers hold. Discussion on this motion may continue. However,
> the motion itself will not be changed during the vote.
>
> A copy of motion 24.03 is found at
>
> http://grouper.ieee.org/groups/1788/private/Motions/Motion24.03.pdf
>
> Please contact me if you need the ID and password for
> the private area.
>
> Sincerely,
>
> Baker
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: I vote NO on Motion P1788/M0024.03:RoundedOperations: ...
> Date: July 6, 2011 7:32:22 AM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
> I have detailed my opinions on this motion in this forum
> extensively.
>
> These instructions were sufficiently important in the
> 70s & 80s to be found (in one form or another) on nearly
> all machines today. And I believe they are still a good
> idea to have hanging around.
>
> I believe that this particular form of all these
> instructions is a good idea even today.
>
> But I believe that it is not our place to mandate any
> particular hardware as a precondition to conforming to
> 1788. Further, that such a mandate might actually hurt
> efficient hardware & software interval implementations.
>
> For these reasons & more I vote NO on this motion.
>
>
> Dan
Begin forwarded message:
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Subject: motion 24.03
> Date: July 6, 2011 10:43:15 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear P1788 members,
>
> if you don't yet know how to vote on motion 24.03 please read the mails sent by Michel Hack and Arnold Neumaier on June 11.
>
> Best wishes
> Ulrich
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Re: Happiness
> Date: June 11, 2011 4:19:01 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Replying to Ulrich Kulisch, Dan Zuras wrote:
>>> So mandating the operations with directed roundings
>>> cannot be a barrier to acceptance of 1788.
>>
>> Perhaps. Perhaps not.
>>
>> It depends on what people like those at Intel think you are
>> mandating.
>
> The mandate would be at the IA runtime level, not at the hardware level.
>
> In a 754 system it is trivial to provide the functions, though perhaps
> they would not perform well in isolation in the absence of hardware
> support. I'll note that I have heard that modern x86 processors have
> the ability to cache the last two rounding modes used to permit switching
> among them with little penalty, so Intel must have thought about this
> already. (The IBM/Sony Cell BE has separate modes for the two halves
> of the vector pipeline, and DFP on IBM's Z already has individual modes
> per operation; other platforms may also. For type conversions explicit
> directed roundings are even more common; IBM have them on both P and Z,
> for BFP as well as for DFP.)
>
> The issue is what a user can expect to find in an IA runtime environment.
>
> If the user wants point-function directed rounding, she could dig through
> blogs (where else do you find compiler information these days?) relevant
> to the platform, write her own (perhaps by converting to an interval and
> extracting a bound, using standard features, or using the underlying 754
> dynamic modes, and give up performance potential), or use the standard
> functions proposed by Motion 24.03. Which sounds more attractive?
>
> As I pointed out before, end users might not need this, but providers of
> IA runtime libraries would... and the functions proposed by this Motion
> are at a low-enough level that library writers could reasonably expect to
> find them even if the full 1788 standard is not present yet (in case the
> library is being written to complete conformance to the full standard).
>
> Michel.
> ---Sent: 2011-06-11 09:42:49 UTC
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Subject: Motion 24.03
> Date: July 6, 2011 11:18:35 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <bill@xxxxxxxxxxx>
>
> My vote is no.
>
> Bill Walster
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Motion 24.03_yes
> Date: July 6, 2011 2:29:56 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 24.03 is: Yes.
>
> I note that the mandate applies to the run-time environment, and
> not necessarily to the hardware (as Dan Zuras appears to imply).
>
> The point is that IF the hardware were to support explicit directed-rounding
> arithmetic efficiently, there should be a UNIFORM way for the programmer to
> exploit this. Otherwise we'll either get suboptimal programs, or an #ifdef
> zoo to handle the subset of platforms that the programmer happens to know
> well enough to exploit uderlying capabilities.
>
> I do admit the possibility that optimizing compilers would be able to
> extract the programmer's intent in low_bound(interval(a)+interval(b))
> and discard the computation leading to the unused high-bound on platforms
> where that would be a separate computation. Perhaps Ian McIntosh could
> enlighten us on how likely that might be. (The standard could include an
> informative note that this could be one way to address the issue -- but
> in that case the platform could easily encapsulate such idioms in macros
> that satisfy Motion 24.03 directly.)
>
> In other words, I still prefer a solution where the programmer can state
> intent directly, instead of relying on side-effects of circumlocutions.
>
> Michel.
> ---Sent: 2011-07-06 19:49:21 UTC
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Question about "system" vs. "hardware"
> Date: July 6, 2011 3:33:32 PM CDT
> To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
>> To: "stds-1788" <STDS-1788@xxxxxxxxxxxxxxxxx>
>> Subject: Question about "system" vs. "hardware"
>> Date: Wed, 6 Jul 2011 10:09:05 -0500
>>
>> Dan,
>>
>> I'm just curious. The motion clearly says:
>>
>> "Every IEEE 1788 compilant system shall provide..."
>>
>> A "system" is any combination of hardware and software. This means I can
>> easily implement a system conforming to Motion 24 on existing Intel and AMD
>> hardware using just a few assembler operations.
>>
>> So how does the motion
>>
>> "mandate particular hardware as a precondition to conforming to 1788"
>>
>> ???
>>
>> Nate
>>
>
>
> Nate,
>
> You are quite correct.
>
> I glanced at version 3 & did not read beyond the first page.
>
> Yes, this removes much of my argument against this motion.
>
> I must admit that if our final document contained EXACTLY
> those words, "system shall provide", I would not be greatly
> vexed.
>
> However, I think I will let my vote stand for now.
>
> Thank you for pointing this out. Others should be guided
> by this.
>
> Yours,
>
> Dan
Begin forwarded message:
> From: Ian McIntosh <ianm@xxxxxxxxxx>
> Subject: Re: P1788/M0024.03:RoundedOperations: NO
> Date: July 7, 2011 5:19:24 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> I vote NO on Motion 24 RoundedOperations.
>
> I vote no because the wording
>
> Each of the 8 operations shall be callable as a single
> instruction. The rounding shall be an integral part of the arithmetic operation. Employing
> an operation with a directed rounding must be as simple as employing the corresponding
> operation with rounding to nearest.
>
> says something I believe is either incorrectly worded or outside our mandate, in many cases impractical, unnecessary, and harmful.
>
> - A "single instruction" and "an integral part of the arithmetic operation" imply to me that each of these operations must be a single hardware instruction. It is not within our mandate to decide what instructions a CPU has. As we discussed earlier, requiring new instructions is impractical.
> Perhaps what was meant was "a single operation", which is not the same thing. An operation may be implemented via multiple instructions, but a single instruction is a single instruction.
> Perhaps what was meant was "a single operation or function", which is also not "a single instruction".
>
> - "an integral part of the arithmetic operation" and "as simple as employing the corresponding operation with rounding to nearest" implies to me that the programming language that interval arithmetic is embedded in must provide a syntax for each of these operations that is as simple as the corresponding operations with default round to nearest rounding. So in a language where a default add is expressed as "+", the directed rounding add "must be as simple". That means no current languages could have interval arithmetic added or embedded in them without defining new operators as easy to use as "+". I expect "x +> y" would be accepted as being as simple as "x + y", but I don't think "addp (x, y)" would be. So languages would need new operator syntax to comply.
>
> - We already agreed that the internal representation of an interval can have one bound negated, and that means that for an interval add both floating point adds can be rounded the same direction. In many cases a series of operations can all be rounded in the same direction. Since a compiler optimizer can often detect that and remove redundant set-rounding-mode instructions, the efficiency difference is diminished. Even if "The rounding shall be an integral part of the arithmetic operation" allowed generating a sequence of instructions (save rm, set rm, add, restore rm), it's not clear that the "integral part" wording would allow merging two such sequences for better performance.
>
> So although I understand the arguments for, although I would like every floating point operation to be able to use either a specific rounding mode or the global one, and although I would like programming languages to be extensible enough that an Interval Arithmetic library or add in could define and use operators like +>, I don't believe 1788 should impose those as requirements. It is outside our mandate. Even if it were not, it would hurt our cause by delaying or prohibiting adoption of the standard.
>
>
> If the wording quoted above were replaced with just
> Each of the 8 operations shall be available as a single operation or function, specifying the arithmetic operations and the rounding mode.
>
> I might vote yes, but I would wonder whether a requirement involving only floating point operations on floating point values, not interval operations on interval values, should be part of 1788 instead of a future 754 revision. It would be useful to floating point users and to interval implementers, but shouldn't interval users avoid such usage?
>
> - Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: P1788/M0024.03:RoundedOperations: NO
> Date: July 7, 2011 7:43:59 PM CDT
> To: Ian McIntosh <ianm@xxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> To: stds-1788@xxxxxxxxxxxxxxxxx
>> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>> From: Ian McIntosh <ianm@xxxxxxxxxx>
>> Date: Thu, 7 Jul 2011 18:19:24 -0400
>>
>>
>> I vote NO on Motion 24 RoundedOperations.
>>
>> I vote no because the wording
>>
>> . . .
>>
>> If the wording quoted above were replaced with just
>>
>> Each of the 8 operations shall be available as a single operation or
>> function, specifying the arithmetic operations and the rounding mode.
>>
>> I might vote yes, but I would wonder whether a requirement involving only
>> floating point operations on floating point values, not interval operations
>> on interval values, should be part of 1788 instead of a future 754
>> revision. It would be useful to floating point users and to interval
>> implementers, but shouldn't interval users avoid such usage?
>>
>> - Ian McIntosh IBM Canada Lab Compiler Back End Support
>> and Development
>>
>
> Ian,
>
> You are working from an earlier version of the motion as
> I was when I voted. If you look at 24.03 you will find
> it is much as you have asked. I still voted no but you
> might want to reconsider.
>
> Just FYI,
>
> Dan
Begin forwarded message:
> From: Ian McIntosh <ianm@xxxxxxxxxx>
> Subject: Re: P1788/M0024.03:RoundedOperations: NO -> YES
> Date: July 7, 2011 8:58:02 PM CDT
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>, <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Thanks. Before I voted I checked the web site to be sure I had the latest version, using the URL from Baker's 07/06/2011 08:03 AM note
>
> A copy of motion 24.03 is found at
> http://grouper.ieee.org/groups/1788/private/Motions/Motion24.03.pdf
> As you say, it is different than the version I copied and pasted from a few hours ago. My browser history shows that earlier today I accessed what looks to me like the same URL
> http://grouper.ieee.org/groups/1788/private/Motions/Motion24.03.pdf .
> Assuming it wasn't just updated, my browser must have reused a cached older version? Was version 2 ever posted using this URL? Very strange. Do you suppose Customs held the new version up at the border? 8<)
>
> I appreciate the changes. Thank you Ulrich.
>
> In favour: I agree that with some syntax (likely as functions in most languages) these operations would be useful for some (but not all) interval arithmetic implementers and math library implementers. The motion no longer implies hardware changes or language syntax changes.
>
> Against: I still believe these operations belong more in 754 than 1788 (along with corresponding operations using the other 754 rounding modes). I still believe that Interval Arithmetic users should use IA operations, then extract the upper and/or lower bounds, instead of using these. But with the changes . . .
> I change my vote to YES but still with some doubts.
>
> - Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Begin forwarded message:
> From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
> Subject: Motion 24.03: NO
> Date: July 8, 2011 2:04:59 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Following Dan Zuras' arguments, I vote NO on Motion 24.03.
>
> FG.
Begin forwarded message:
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 24.03: NO
> Date: July 10, 2011 7:51:02 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear 1788 members,
>
> The motion says:
> " Every IEEE 1788 compliant system shall provide the four basic arithmetic
> operations addition, subtraction, multiplication, and division with rounding downwards and
> upwards. Type conversions with directed roundings shall also be provided."
>
> If we decide to base 1788 on 754 then I do not see any need for this specific motion. Any 754 compliant system MUST provide what this motion requires. The relevant part from 754-2008 is on page 16:
>
> "An implementation of this standard shall provide roundTiesToEven and the three directed rounding
> attributes. A decimal format implementation of this standard shall provide roundTiesToAway as a user-
> selectable rounding-direction attribute. The rounding attribute roundTiesToAway is not required for a
> binary format implementation."
>
> In order to correctly keep what is 754 within 754 and what is 1788 within 1788 I vote NO on motion 24.03.
>
> --
> Hossam A. H. Fahmy
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Re: Motion 24.03: NO
> Date: July 10, 2011 8:37:30 AM CDT
> To: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxx>
>
> Hossam, P-1788,
>
> My understanding of the difference between 754 and 24.03
> is the distinction between "rounding attribute" and
> "operation." The "rounding attribute" typically
> (but not always) has been implemented as a processor
> state, with associated efficiency issues when the
> rounding mode is changed. I believe (and correct me
> if I am wrong) the proposers of Motion 24.03 feel
> efficiency can be gained with an implementation
> of separate opcodes (addup, adddown, addnear, etc.) rather than
> forcing a processor mode change every time a different rounding
> direction from the previous operation is required.
>
> Of course, within the standard wording itself, the operations
> can be implemented, in software, on top of mode changes,
> or the mode changes can be implemented on top of the operations, so
> there really is little difference. However, language does affect how
> people think about things, and, I think, the hope of the
> proponents of 24.03 is chip designers might seriously consider
> separate opcodes rather than modes. I believe, however, that
> would be a significant change for, say, the Intel line. (People,
> please correct me.)
>
> I did some experiments in timing interval arithmetic on desktops
> of about 15 years ago. I found, in a loop, say, with 10^6 or so
> additions (unrolled to limit loop overhead), changing the rounding
> mode was MUCH slower than sacrificing accuracy by simulating
> directed rounding. In my simulations, I would, say, for an addition,
> do the addition with rounding to nearest in effect, then
> multiply the result by (1+\epsilon) for simulated upward rounding.
> The difference was so large that I used the simulated rounding
> in my work.
> I haven't done such experiments with more recent chips and compilers.
>
> You may know that interval arithmetic may be done on mode-based hardware
> without changing the rounding mode, by storing [a,b], say, as
> <-a,b>, but that has its own issues ...
>
> Baker
Begin forwarded message:
> From: Alexandru Amaricai <amaricai@xxxxxxxxx>
> Subject: Motion 24
> Date: July 11, 2011 10:26:51 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on motion 24.
>
> Alexandru Amaricai
Begin forwarded message:
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Subject: Some thoughts on motion 24.03
> Date: July 12, 2011 2:06:08 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I wanted to add a few reasons for voting Yes on motion 24.03 but forgot, so here they are. I agree with Dan Zuras's objections in many ways but think they are missing the point. I had a compromise suggestion, but Michel & Vincent didn't think much of it, so I go with the motion as stated.
>
> I see this as about, not "what hardware should do", but "what implementations provide". If 1788 is implemented as a library, then operations "add with rounding upwards", etc., are to be available as named operations in the library. These features aid writing library code that is concise and portable. I see them as part of the infrastructure, "level 3.5" say, for coding this same library, i.e. for coding level 3. No matter if a crude version of them is 100 times as slow as optimised code on some platforms. If they bring forward by 6 months the release of the first complete, fully tested, highly portable, P1788 library (I think they might) they will have justified their existence. Then one can tune for speed, by many methods of known effectiveness.
>
> John Pryce
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motion 24.03 NO
> Date: July 12, 2011 9:19:02 AM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 24.03.
>
> I have already detailed my opinions. The motion has improved a bit
> (it is fine that it no longer mentions hardware). But:
>
> 1. This shouldn't belong to P1788, but to the floating-point arithmetic
> and language standards (IEEE 754-1985 already defines these operations,
> and it will be available in general, and if it is not, there may be a
> good reason, and no problems will be solved concerning P1788).
>
> Moreover the motion doesn't detail how rounding upwards, etc. is
> defined. Is this correct rounding? With exceptions? How should they
> be handled? and so on... Detailing everything would be quite complex
> for P1788, and that's also why such requirements are better provided
> by floating-point arithmetic (e.g. IEEE 754) and language standards
> (let's also mention LIA).
>
> 2. I still disgree about the list of the operations. Why not all
> operations (functions) supported by P1788?
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 24.03: NO
> Date: July 12, 2011 9:37:28 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2011-07-10 08:37:30 -0500, Ralph Baker Kearfott wrote:
>> Hossam, P-1788,
>>
>> My understanding of the difference between 754 and 24.03
>> is the distinction between "rounding attribute" and
>> "operation." The "rounding attribute" typically
>> (but not always) has been implemented as a processor
>> state, with associated efficiency issues when the
>> rounding mode is changed. I believe (and correct me
>> if I am wrong) the proposers of Motion 24.03 feel
>> efficiency can be gained with an implementation
>> of separate opcodes (addup, adddown, addnear, etc.) rather than
>> forcing a processor mode change every time a different rounding
>> direction from the previous operation is required.
> [...]
>
> But P1788 is not about hardware. Motion 24.03 could be fine for
> a processor standard (that would be completely be different from
> P1788).
>
> An informational note could say that P1788 would be best implemented
> on hardware that supports directed rounding (possibly except for a
> direct hardware implementation of P1788), but this wouldn't even be
> sufficient, as the language used for the implementation must also
> support directed rounding (this is not the case of ECMAScript, for
> instance).
>
> Note that the requirements are for the users of the standard, not
> for the implementer.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
> Subject: Re: PLEASE VOTE P1788/M0024.03:RoundedOperations: PLEASE VOTE
> Date: July 14, 2011 8:27:47 PM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> No.
>
> Lee Winter
Begin forwarded message:
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Subject: Re: Motion 24.03 NO
> Date: July 22, 2011 12:24:27 PM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Am 12.07.2011 16:19, schrieb Vincent Lefevre:
>> I vote NO on Motion 24.03.
>
>> 1. This shouldn't belong to P1788, but to the floating-point arithmetic
>> and language standards (IEEE 754-1985 already defines these operations,
>> and it will be available in general, and if it is not, there may be a
>> good reason, and no problems will be solved concerning P1788).
> IEEE 754 is primarily concerned standardizing floating-point arithmetic with rounding to nearest.
>
> For better support of verified computing (computing with guarantees) the standards committee "IEEE P1788 for interval arithmetic" was founded. Would the committee have been called "P1788 for verified computing" or "P1788 for computing with guarantees" it would be more obvious that the operations and conversions with directed roundings belong into P1788. These operations (as an exact dot product) are essential engredients of computing with guarantees.
>
> --
> Karlsruher Institut für Technologie (KIT)
> Institut für Angewandte und Numerische Mathematik (IANM2)
> D-76128 Karlsruhe, Germany
> Prof. Ulrich Kulisch
Begin forwarded message:
> From: Zimmermann Paul <Paul.Zimmermann@xxxxxxxx>
> Subject: Re: Motion 24.03 NO
> Date: July 22, 2011 12:34:36 PM CDT
> To: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Cc: <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Dear Prof. Kulisch,
>
>> IEEE 754 is primarily concerned standardizing floating-point arithmetic
>> with rounding to nearest.
>
> did you read the 2008 revision of IEEE 754, in particular Section 4.3.2
> (Directed rounding attributes) and 4.3.3 "An implementation of this standard
> shall provide roundTiesToEven and the three directed rounding attributes"?
>
> Paul Zimmermann
Begin forwarded message:
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Subject: Re: Motion 24.03 NO
> Date: July 22, 2011 2:11:54 PM CDT
> To: Zimmermann Paul <Paul.Zimmermann@xxxxxxxx>
> Cc: <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Paul:
>
> Thank you for your remark. I am familiar with the text below. But I am also familiar with the problems we have with existing implementations. So my mail says: the operations and conversions with directed roundings belong into P1788. In an earlier mail I said:
>
> The motion stresses the basic meaning of the requested operations for verified computing.
>
> Best wishes
> Ulrich Kulisch
>
>
>
> Am 22.07.2011 19:34, schrieb Zimmermann Paul:
>> Dear Prof. Kulisch,
>>
>>
>>> IEEE 754 is primarily concerned standardizing floating-point arithmetic
>>> with rounding to nearest.
>>>
>> did you read the 2008 revision of IEEE 754, in particular Section 4.3.2
>> (Directed rounding attributes) and 4.3.3 "An implementation of this standard
>> shall provide roundTiesToEven and the three directed rounding attributes"?
>>
>> Paul Zimmermann
>>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 24.03 NO
> Date: July 24, 2011 3:47:45 AM CDT
> To: <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> On 2011-07-22 21:11:54 +0200, Ulrich Kulisch wrote:
>> Paul:
>>
>> Thank you for your remark. I am familiar with the text below. But I am also
>> familiar with the problems we have with existing implementations.
>
> If directed roundings are not already implemented, having them
> as a requirement in P1788 won't change anything (they could be
> implemented to make the implementation of IA easier, but this
> is independent of this motion).
>
>> So my mail says: the operations and conversions with directed
>> roundings belong into P1788. In an earlier mail I said:
>>
>> The motion stresses the basic meaning of the requested operations for
>> verified computing.
>
> Why only the arithmetic operations and conversions? Elementary
> functions are important too.
>
> Also, you don't necessarily need correct rounding to compute
> bounds.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Dorina Lanza <dorinalanza@xxxxxxxxx>
> Subject: Re: M0024.03: PLEASE VOTE
> Date: July 24, 2011 11:04:03 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> I vote no because it is unnecessary.
Begin forwarded message:
> From: "Hanek, Bob" <bob.hanek@xxxxxxxxx>
> Subject: Re: Motion 24.03 NO
> Date: July 26, 2011 12:38:49 PM CDT
> To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
>
>
Begin forwarded message:
> From: Nathalie Revol <Nathalie.Revol@xxxxxxxxxxx>
> Subject: Motion 24.03: NO
> Date: July 27, 2011 2:07:06 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO to Motion 24.03.
>
> I agree with the reasons given by Vincent Lefevre.
> The main reasons are
> - I think i belongs to IEEE 754
> - I feel it is possible to implement interval arithmetic without directed
> roundings (and without maximal accuracy): see Fi_Lib.
>
> Best regards
> Nathalie Revol
Begin forwarded message:
> From: Stefan Siegel <St.Siegel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 24.03: NO
> Date: July 27, 2011 2:29:53 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <St.Siegel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> I vote NO to Motion 24.03.
>
> I see the same reasons as Nathalie Revol and Vincent Lefevre.
>
> Stefan
Begin forwarded message:
> From: "Evgenija D. Popova" <epopova@xxxxxxxxxx>
> Subject: Motion M0024.03: NO
> Date: July 27, 2011 4:03:52 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: <george.corliss@xxxxxxxxxxxxx>
> Reply-To: <epopova@xxxxxxxxxx>
>
> I vote NO on Motion 24.03.
>
> I agree with the reasons presented by Vincent Lefevre.
>
> Evgenija Popova
Begin forwarded message:
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion 24.03: NO
> Date: July 27, 2011 7:19:52 AM CDT
> To: <stds-1788@xxxxxxxx>
>
> I vote NO for Motion 24.03
>
> I agree with Vincent Lefevre and Nathalie Revol.
>
> Additionally I think the requirement of this operations with directed rounding and maximal accuracy will block (efficient) implementations on some systems. For example on GPU's it is necessary for the maximal performance that all threads perform the same operations simultaneously. If we use algorithms (on GPU's without directed rounding) to simulate the directed rounding with one ulp accuracy and as long as this algorithms use branches than the computation is performed sequentially. Hence, we lose the power of this highly parallel system. On the other hand if we use round to nearest for the operation and then multiply by (1+\epsilon) we lose the maximal accuracy but we can perform this operations in parallel.
>
> And as mentioned in my mail from July 20 I am in doubt that this motion fits into the specifications of other languages/systems like Java (or all the other Java VM languages).
>
> Therefore I think this motion work against early and widespread acceptance of the standard.
>
> Best regards
>
> Marco
Begin forwarded message:
> From: Małgorzata Jankowska <malgorzata.jankowska@xxxxxxxxxxxxx>
> Subject: MOTION 24.03: NO
> Date: July 27, 2011 9:46:30 AM CDT
> To: <stds-1788@xxxxxxxx>
>
> My vote is NO.
> After consideration I agree with most remarks against the motion considered.
>
> Best regards
> Malgorzata Jankowska
Begin forwarded message:
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Subject: P1788/M0024.03:RoundedOperations: NO
> Date: July 27, 2011 2:56:58 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on the motion is NO following Vincent's reasoning.
>
> Best,
>
> Christian
Begin forwarded message:
> From: David Lester <David.Lester@xxxxxxxxxxxx>
> Subject: P1788/M0024.03:RoundedOperations: NO
> Date: July 27, 2011 3:30:11 PM CDT
> To: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Like Nathalie and Vincent, I vote No.
>
> Dave Lester
============================================================
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: P1788/M0024.03:RoundedOperations: PLEASE VOTE
> Date: July 19, 2011 8:13:43 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>> Current tally: 27 Yes; 7 No; required for quorum: 38
>
> In other words, we just need four more NO votes for the motion to pass. :(
>
> Come on guys and gals, aren't some of us mathematicians? Can we not come
> up with a sensible quorum rule that avoids this issue? This came up before,
> but eventually the discussion fizzled without resolution.
>
> Perhaps the problem is inherent in open voting. We don't want to pass a
> motion without a reasonable quorum, but it also seems silly that deliberate
> refusal to vote can be used to force an outcome. The exclusion from further
> voting after two non-votes was supposed to stabilize the procedure (by making
> the next quorum smaller) -- but I haven't heard this rule mentioned recently,
> perhaps because it doesn't apply to position papers.
>
> Here is one possible rule: If the quorum has not been reached by the end
> of the voting period, but either YES or NO votes exceed quorum/2, then the
> quorum is deemed to have been reached. This avoids a motion being passed
> by too small a number of votes, but also avoids the problem at hand.
>
> Michel.
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: P1788/M0024.03:RoundedOperations: PLEASE VOTE
> Date: July 19, 2011 1:45:52 PM CDT
> To: <rbk@xxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> Date: Tue, 19 Jul 2011 10:44:20 -0500
>> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
>> To: Michel Hack <hack@xxxxxxxxxxxxxx>
>> CC: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>> Subject: Re: P1788/M0024.03:RoundedOperations: PLEASE VOTE
>>
>> Michel,
>>
>> I would need to dig deep into my records at this point to
>> see what parts of our approved P&P are specific to us and
>> what parts (I believe most) are pre-specified by IEEE.
>> It would not be trivial, and it would take some time
>> (with official approval from appropriate IEEE bodies) to
>> change our P&P at this point. Furthermore, IEEE requires
>> some parts. In any case, I don't think it is a good idea
>> to change the rules in the middle of a particular vote.
>>
>> Regarding removal from the roster for non-voting, that is
>> definitely being enforced independently of the outcome
>> of any particular vote. This is analogous to a widespread
>> rule in standards bodies to remove people from the roster
>> who fail to attend two in-person meetings; it is meant
>> to make it possible to continue to conduct business when
>> there are inactive participants, and also to encourage
>> participation.
>>
>> Baker
>>
>> On 7/19/2011 8:13 AM, Michel Hack wrote:
>>>> Current tally: 27 Yes; 7 No; required for quorum: 38
>>>
>>> . . .
>>>
>>> Here is one possible rule: If the quorum has not been reached by the end
>>> of the voting period, but either YES or NO votes exceed quorum/2, then the
>>> quorum is deemed to have been reached. This avoids a motion being passed
>>> by too small a number of votes, but also avoids the problem at hand.
>>>
>>> Michel.
>>> ---Sent: 2011-07-19 13:34:51 UTC
>>>
>>
>
> Michel & Baker,
>
> We need not dig deep into the records nor come up with
> any new rules. This situation is covered by the existing
> rules.
>
> I include (an edited version of) my comments on this
> matter when it came up last year.
>
> In it I state that I will call for the quorum with each
> vote. I was angry at the time. It turns out that this
> is unnecessary &, as I recall, Baker took it as such.
>
> An online vote IS ALSO a quorum call. Failure to answer
> two quorum calls in a row results in being dropped from
> the roster of eligible voters.
>
> A motion that fails due to lack of quorum has not been
> rejected & may be resubmitted. Thus the problem resolves
> itself by reducing the size of a quorum & permitting the
> motion in question to be resubmitted to a now smaller
> voting body with a smaller quorum & fewer non-participants
> involved.
>
> So vote on the current motion or not. Either way this
> standard will be written by those who show up.
>
>
> Dan
>
>
>> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>> Date: Mon, 22 Nov 2010 04:46:30 -0800
>>
>>>
>>> . . .
>>>
>>
>> I do not approve of this peculiar behavior.
>> It is twisting the 17th century rules for polite
>> behavior to take advantage of our relatively
>> anonymous 21st century way of meeting.
>>
>> There is a saying: They have power who have the
>> power to say no.
>>
>> You are using this behavior to amplify that power
>> to the point of jeopardizing this standard.
>>
>> Very well, let's see if old Robert was clever
>> enough to account for that.
>>
>> Under section 10.1 of our Policies & Procedures
>> (which we all voted for when we began this thing)
>> I formally ask the chair for a quorum call before
>> each vote. I find it acceptable that it be carried
>> out in parallel with each vote. I further find it
>> acceptable that a yea or nay vote be counted as
>> 'present' in the quorum call. Both the quorum & the
>> outcome of the vote will, therefore, be determined
>> by the number of members that answer the quorum call.
>>
>> Quoting from paragraph 2 of section 8.2 we have:
>>
>> Each member is expected to remain informed
>> of working group business, either through
>> attending meetings or through electronic
>> means, and to participate in votes. The
>> Secretary (or Vote Tabulator, as appropriate)
>> records who votes. Those who fail to vote on
>> two consecutive issues will be dropped from
>> the roster. These persons can have their
>> voting privileges reinstated by again
>> officially placing themselves on the roster.
>>
>> Therefore, under section 8.2 of the P&P, I further
>> formally ask that those not participating in two votes
>> in a row be dropped from the roster. The convention
>> in 754 was to have someone answer 2 quorum calls in
>> a row before being given the right to vote again.
>> I don't see text in the P&P for that but it was the
>> rule I used & the IEEE supported it.
>>
>> There is supporting text for all of this in sections
>> 10.1, 10.4, 8.2, & 4.
>>
>> I apologise to our vote tabulator for making this
>> request formally but it seems that something like
>> this is being forced on us to prevent this standard
>> from being defeated from within.
>>
>>
>> Dan