No subject

[uunet!research.att.com!dmg]

to- Free Tydeman (tydemanaibmpa.awdpa.ibm.com uunet!validgh.com!numeric-interestauunet.uu.net)
from- David M. Gay
re- underflow

I believe the numerical results reported in your "Underflow bug"
message are correct: your chip is behaving in accordance with the
IEEE standard.

When converting doubles in [FLT_MIN*(1-FLT_EPSILON), FLT_MIN)
to float, it first rounds the result to float, assuming an
unbounded exponent range.  If, after this rounding,
the exponent is too small, it denormalizes the result,
i.e., it detects tininess *after* rounding.
It sets the inexact bit if either the initial rounding
to float or denormalization discarded any bits.  It sets
the underflow bit if it has detected tininess and the
result is inexact.

For dbl=380fffffe0000000, the initially rounded float has
significand 1.fffffe (where the 1 is implicit), and the
result (so far) is exact.  However, the exponent is too
small: tininess is detected.  Denormalizing the result
involves the round-even rule, which rounds the result up
to FLT_MIN and sets inexact.  Tininess and inexact
together imply underflow.  Values in [380ffffff0000000,
380fffffffffffff] are initially rounded to FLT_MIN, so
tininess is not detected and underflow is not set.

-- Dave