Re: Hack's recirculation ballot on P754 draft 1.6.0

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

> One *could* argue that neither should signal Inexact, and that if a
> program wants to detect a change in value, it can always compare the
> "before" and "after" values (and raise an exception if desired), but
> that is not something I would like to change at this time.

In general, why do we have an inexact exception when a comparison could be
done of the final result and the operand?

One reason is that the unrounded result comparand isn't available anywhere
for the usual operations +-*/.   But if that were the only reason,
one might conclude that value-changing 
operations like conversions or rounding to integral don't really need
to signal an inexact exception.

But the other reason is that we would like to not delay the normal case
by checking for an uncommon exceptional case.     So one could set up a
loop and trap immediately to different code is inexact is signaled, or
one could test the inexact flag at the end, in neither case slowing down
the normal case within the loop.    As a matter of fact, these are 
called "immediate" and "delayed" alternate exception handling attributes,
and if the "delayed" were required to be provided then most application
programmers would never have to figure out the save/clear/test/restore flag
sequences and the suitability of their progamming interface
wouldn't matter so much.

On the other hand, if round to integral and quantize were not likely to
figure in performance-critical inner loops, one might conclude that 
they should not signal inexact and programmers should use comparisons
when interested.

But finally, there is a hope in 754 that unrequited exception flags 
standing at the end of a program might be investigated.     If exceptions
were replaced by comparisons, they might lose a hint of program error.
However the
inexact flag is almost always raised normally by the end of the program
and hence isn't likely to generate much investigational interest.