Re: P1788/M0024.03:RoundedOperations: NO

[Ian McIntosh <ianm@xxxxxxxxxx>]

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

"Corliss, George" ---07/07/2011 06:29:26 AM---P1788, Voting for Motion M0024.03:RoundedOperations is now in progress.

From:	"Corliss, George" <george.corliss@xxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	07/07/2011 06:29 AM
Subject:	P1788/M0024.03:RoundedOperations: PLEASE VOTE

---

P1788,

Voting for Motion M0024.03:RoundedOperations is now in progress.
Baker's announcement is appended below.

Current tally: 9 Yes; 2 No; required for quorum: 37

I appreciate the early volume of voting :-)

George Corliss
P1788 Voting Tabulator

On Jul 6, 2011, at 7:01 AM, Ralph Baker Kearfott wrote:

>   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
> 
>    P.S. Juergen: Please update this motion's status on the IEEE
>         web site.
> 
> -- 
> 
> ---------------------------------------------------------------
> Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
> (337) 482-5270 (work)                     (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------

Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg