Re: extreme exponent spill definitions

[Guillaume Melquiond <guillaume.melquiond@xxxxxxxxxxx>]

Le lundi 15 octobre 2007 à 07:44 -0700, David Hough 754R work a écrit :
> > > The opposite extreme definition is:
> > > the numerical result rounded to the destination format differs from the
> > > numerical result rounded to a hypothetical format with the same precision
> > > as the destination format but unbounded exponent range.
> >
> > Could you detail a situation where [this] definition will not
> > satisfy everybody? It seems like this is the definition that any user
> > actually expects. For example, if a developer checks the sticky flags
> > (or trap exceptions) in order to ensure that a sequence of operations
> > did not go astray (bounded relative error as predicted by the model),
> > then both definitions work. But only the second one has the advantage of
> > never raising a false positive.
>
> 1) This definition does not signal an exact subnormal result.
> Some people want underflow signaled in that case, in order to wrap exponents
> for instance, or to implement abrupt underflow in software.

Is that so? The definition for after-rounding underflow says "Tininess
is detected when a non-zero result computed as though the exponent range
were unbounded would lie strictly between +/- b^emin." So it seems to me
that a subnormal result, whether exact or not, is tiny, as it is smaller
than b^emin.

Could it be that you were considering a different definition than the
standard one for after-rounding underflow? I had assumed you were just
rewording the legalese prose, and it seems Mike Cowlishaw understood
like me, as he mentioned that the only behavioral difference was for
results around b^emin. Sorry for the confusion.

> 2) This definition is actually rather hard to translate from words into
> efficient hardware.    It's never been implemented as far as I know.
> The problem is excluding the cases that round to the same value that they
> would have rounded to in the hypothetical format.

I agree that, if a method cannot be properly implemented in hardware,
then a fail-safe variation should be proposed. In other words, an
implementation can detect a few false-positives, but it should fail to
detect true-positives (that is, false-negatives).

So an environment providing before-rounding while the user expects
after-rounding will generate false-positives, which is acceptable, as
long as there is not too many of it. But an environment providing
after-rounding while the user expects before-rounding will generate
false-negatives, which is bad and may have life-critical consequences.
(Think of the controller of an X-ray device that would compute an
exposure time with no correct digits, this is lethal, and it has
actually happened.)

So, slightly reworded, my question is: Are there algorithms that will
awfully break if a result signals before-rounding underflow but does not
signal after-rounding underflow? Does anyone know of such an example?
Michel Hack's floating-point operation that produces no significant
digits when rounding away from zero would be a good example of such a
failure.

Best regards,

Guillaume