Re: Motion 4: P1788 on non-754?
IEEE 754 isn't perfect but it offers
more "features" (rounding modes, subnormals, infinities, NaNs,
multiple precisions and exponent ranges, binary or decimal base) than other
floating-point designs.
I support what I think is the intent
of this motion, which I believe is for us to start by assuming all that
capability as our starting point. But . . .
Once we've defined what the IEEE 1788
Interval Arithmetic operations should do, exactly, and how they
should interrelate (and note there are steps we should be doing even before
that), and are all in agreement with that, comes the next step: Review
the operations and interactions to determine what floating point requirements
they impose on the underlying hardware+software floating point implementation.
We may, for example, decide that infinities are essential at least
as lower and upper bounds, meaning that if a non-754 system wanted to follow
the standard it, it would have to have some hardware or software representation
of infinity. We may decide that using the 754 bit patterns is necessary,
or we may decide that conversion to and from that as a "data interchange
standard representation" is enough, or we may impose no bit pattern
rules at all.
I hope that our standard allows not
just IEEE 754 binary64 (double precision) but also other IEEE 754 formats:
binary32, binary128, binary64x (Intel's 80 bit version and others'
128 bit versions), decimal32, decimal64, decimal128, arbitrary precision
- whatever the implementers and user decide to use. It's likely that
we can allow some non-IEEE formats like PPC "double double" despite
the fact that it sometimes gives more than 106 bits (whenever there are
zero bits between the upper 53 and the lower 53). CELL SPU single
precision and others which lack subnormals may be ok despite losing precision
around zero. CELL SPU single precision may have a bigger problem
in lacking infinities (and NaNs).
All those decisions depend on what functionality
the operations we define need. The requirements are not just a hardware
issue. If the hardware is deficient and one is willing to pay in
speed and code size or function calls, software can fill in. The
question is whether it's practical, but that's a decision for implementers
and users not for the standard committee. Users may prefer a slow
implementation for the computer they have over having to buy a different
computer.
I support what I think is the intent
of this motion now, to let us get on with the important issues, but I also
strongly support refining it later when it's time.
- Ian McIntosh
Toronto IBM Lab 8200 Warden D2-445