Re: after-rounding tininess detection and directed rounding

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

John Harrison wrote:
> Anyway, whatever the rights and wrongs of the definitions, I'm quite
> surprised to see such a fundamental change in the standard appear this
> late in the revision process.

There is no fundamental change in the standard -- the native method for
tininess detection can still be before or after.  What is new is the
optional "reproducibility" attribute, which, when supported, requires
a fixed choice for tininess detection -- currently "after rounding".

It seems to me that "before rounding" would have been a better common
choice, because (a) it would match what is required for decimal formats,
and (b)  I think it is easier to signal a missing exception than to cover
up (without visible side-effects) an unwanted exception -- except in the
few cases where the platform supports a restartable trapping mechanism
with no visible side-effects, such as IBM's System z -- but not System p.

Since I was confused about the precise definition of "after rounding" I
will have to re-examine my emulation analysis.  I shall report what I find.

Michel.

P.S.  There is actually one change in the standard for Underflow detection:
      The old standard also permitted two ways to detect loss of accuracy,
      but only one of those was ever implemented (inexact result), so the
      other option was quietly removed.
Sent: 2007-10-15 20:47:37 UTC