Re: reproducibility of tininess detection for binary formats

[David Hough 754R work <754r@xxxxxxxxxxx>]

> I think you got it backwards.  If you want "before rounding" semantics
> as you say, but the machine detects "after rounding", there won't be any
> unwanted exceptions to undo.  Instead, Nmin results have to be checked
> to see whether a delayed exception needs to be raised explicitly.  

The question is whether it's easier to turn off extra signals vs turn on
extra signals.    Assuming some kind of reasonable trapping mechanism -
machine specific so the trapping mechanism itself needn't be portable or
expressible in higher level language - turning off extra signals with
a trap that occurs only on signals is bound to be more efficient than 
testing every unexceptional operation to see if it should have signaled.
If, however, one wants to do something equivalent in portable higher level
language, then one is stuck with something very expensive in the normal
case.     All for something that almost nobody cares about.

> This
> is also what I want, but P754-150 currently demands the opposite.
> At this point I'm not sure whether you agree or disagree with the current
> P754-150 proposal in clause 11, page 60 line 33.

The current draft does not express a preference between tininess criteria
for normal mode.     For reproducible mode, there is a required tininess
criterion, but reproducible mode is optional, and as I explained earlier, 
I don't think any language standards committees are likely to develop a 
consensus that it's a worthwhile option to pursue.    A reproducible mode
is only interesting if it can be at least as efficient, on average, 
as unoptimized normal mode - if it has to be provided by a complete
software implementation of all operations that might underflow, it's
not interesting.    As I indicated, there are two plausible ways
around that, neither of which has much support at the moment.