Re: after-rounding tininess detection and directed rounding

[John R Harrison <johnh@xxxxxxxxxxxxxxxx>]

Hi Michel,

| The reason for allowing a choice is the need to accomodate existing
| implementations -- and where this was not an issue, rules could be
| tightened, and were.  This also covers the new "reproducible mode"
| attribute.

In practical political terms, this is no doubt true. However, there is
in principle some intellectual benefit in allowing choice, because it
doesn't prematurely close off the space of possible future
implementations. I'd rather have kept a free choice for tininess
detection in both formats, at least in the main section.

In general this kind of nondeterminism may seem undesirable, but as
has been noted by others, there are already many other more
troublesome sources of dondeterminism. Tininess detection is one of
the more obscure, and one that doesn't directly affect numerical
results.

I suspect only 1% of programmers care about underflow detection in 1%
of programs. Since only 1% of those also care about cross-platform
reproducibility, is it worth an incompatible restriction on the
standard at this late stage? Particularly when it enshrines a choice
that is, arguably, technically inferior. (I mean both the requirement
that decimal tininess be detected before rounding.)

John.