IEEE floating point format

[D. Jason Penney]

In article <3591 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
>Next question:  do C compilers (math libraries, I expect I should mean)
>on IEEE-FP-implementing machines generally limit doubles to normalized
>numbers, or do they blithely allow precision to waft away in the name
>of a slight increase in the number-range?
>
>I expect the answer is "the compiler has nothing to do with it", so the
>next question would be, are there machines that don't permit the loss
>of precision without specific orders to do so?

This is an interesting question.  The early drafts of IEEE P754 had a
"warning mode" -- When "warning mode" was set, an operation with
normal operands that produced a subnormal result 
("subnormal" is the preferred term instead of "denormalized" now, by the way),
an exception was signalled.

It was eventually removed because 1) Checking for this condition
was expensive, and 2) it did not seem to be very useful.

The use of subnormal representations actually caused quite a bit of
controversy, by the way.  Most pre-IEEE floating points underflow from
the lowest normalized value directly to true zero.  IEEE 754 and 854 support
the notion of "gradual underflow", where precision is gradually lost
(through the use of subnormal values).

I won't give a full discussion of the benefit of gradual underflow, but
note that with truncating underflow, it is possible to have two floating 
point values X and Y such that X != Y and yet (X - Y) == 0.0, 
thus vitiating such precautions as,

if (X == Y)
  perror("zero divide");
else
  something = 1.0 / (X - Y);

[Example thanks to Professor Kahan...]

-- 
D. Jason Penney                  Ph: (503) 629-8383
Beaverton, OR 97006              uucp: ...uunet!servio!penneyj
STANDARD DISCLAIMER:  Should I or my opinions be caught or killed, the
company will disavow any knowledge of my actions...