Re: [STDS-754] reproducibility of tininess detection for binary formats

[Guillaume Melquiond <guillaume.melquiond@xxxxxxxxxxx>]

Le lundi 15 octobre 2007 à 08:57 +0100, Mike Cowlishaw a écrit :

> > Could you detail a situation where the second 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.
>
> I can.  Consider an implementation that provides a Subnormal flag (which 
> means: the magnitude of the result of the operation was less than that of 
> the smallest normal number (Nmin, = b**emin)).  In such an implementation, 
> the first definition trivially defines Underflow as Subnormal & Inexact. 
>
> This is easy to document and to explain to users: "Underflow is a when the 
> magnitude of a result is less than Nmin and cannot be represented 
> exactly".  To me, 'this is the definition that any user actually expects'.

Sorry, I am missing part of your point. I understand the part about the
first definition being easier to define. But I don't see where it
translates to being more useful for the user than the second definition.

In my experience, the primary (only?) use of these flags/traps is to
detect when the ideal model of floating-point arithmetic (unbounded
exponent range, as usually assumed by backward error analysis for
example) no longer applies to a given computation.

So can you please detail a practical use case where the second
definition would fail to give a proper answer, but the first one would?
This is what my first mail was about: Is there a situation where the
first definition gives an answer more useful than the first definition.

Guillaume