Re: Motion 24.03: NO
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
On 07/10/2011 07:51 AM, Hossam A. H. Fahmy wrote:
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
Associate Professor
Electronics and Communications Department
Cairo University
Egypt
--
---------------------------------------------------------------
R. 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
---------------------------------------------------------------