reproducibility of tininess detection for binary formats

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

This is the other of the two ambiguities in the standard that is supposed
to be resolved in a particular way by the "reproducible results" attribute.

In my IEEE-SA ballot response I was going to argue that this conformance
be dropped (see my previous ballot-preview post), because it is expensive
to provide a side-effect-free coverup when the native behavious differs,
yet -- or so I thought -- easy to handle when the program is aware of the
issue.  After all, the result of underflow is the same, so the only issue
is reproducible exception flags and triggering of alternate (explicit)
underflow handling.  The proposed way of handling it means suppressing
some underflows that result in Nmin.

The problem is that, in default exception handling, the evidence will be
gone by the time the program checks for summary underflow, and in most
forms of alternate exception handling, it is difficult to undo the likely
transfer of control.  Two kinds of alternate exception handling are however
capable of dealing with the situation: restartable, and substitute of Nmin
with the sign of the result.

I suppose the after-rounding rule was chosen as the "reproducible" one
because, although simulating it can be expensive when the native rule
detects tininess before rounding, the opposite simulation is likely to
be even more expensive, because it would have to recompute every Nmin
result with higher precision in order to determine whether it might have
had to signal Underflow.  Yikes.  (Well, higher precision may not be
necessary; I need to perform some analysis, but it is conceivable that
a recomputation with one or the other operand suitably scaled could be
carried out at the same precision.  This is still expensive.)

Either way looks expensive however, as every single multiplication or
division would have to be followed by a check for an Nmin result.  Here
is where the difference between language-provided coverup and "manual"
coverup by the program lies:  in situations where Inexact is ignored
because it is almost always expected, a program could simply raise the
Underflow flag when a multiplication or division returns Nmin.  Sometimes
this would be an overindication, but it would not depend on the details
of tininess detection, and the program does not care:  it would satisfy
the reproducibility requirement.

Now, if a program really depends on proper Inexact reflection, or on
proper alternate-exception transfer, I agree that the coverup has to be
provided by the compiler, as the burden on the programmer to deal with
this effectively would then be unreasonable.  This makes me wonder whether
the reproducibility attribute should have several degrees, instead of
being all-or-nothing.

At the very least, programming environments should be required to provide
a program-accessible test as to which variant of a variant property (such
as tininess detection, or fma behaviour for that matter) is present, so
programs can decide, based on their requirements, how to cope with this.
The cost of the alternatives should also be known to a reasonable extent.

Have others evaluated the relative cost of the two alternatives for this?
It seems a shame to pick the less-preferred tininess detection rule, i.e.
the one that differs from the one chosen for decimal:  really excessive
cost for the other way seems to be the only justification.

Michel.

P.S.  In the light of my own analysis I may have to tone down my ballot
      comments on fma() and tininess.  I'm still concerned however, and
      would welcome a serious technical discussion on merits and costs.
Sent: 2007-10-14 00:05:03 UTC