More on Inexact definition in Clause 7.6

[Michel Hack <hack@xxxxxxxxxxxxxx>]

Here is the current text:

   If the rounded result of an operation is inexact - that
   is, it differs from what would have been computed were
   both exponent range and precision unbounded - then the
   inexact exception shall be signaled.

Consider a typical conversion operation.  As the target
precision is increased (hypothetically -- this is not tied
to existing formats), the value may change, until eventually
it is exact (or possibly forever, in the case of decimal to
binary conversion).

Now consider the result of roundToIntegralExact.  As the
target precision is increased, the number of leading zeros
(for a decimal significand) or trailing zeros (for a binary
significand) increases, but the value remains unchanged.

The same is true for quantize (for decimal).  Indeed, for
non-integral operand x, roundToIntegralExact(x) is simply
a special case of quantize(x,1).

THAT's why quantize and roundToIntegralExact constitute
a special case that is not covered by the current 7.6
definition of Inexact.

Thanks largely to Ron Smith, the IBM System Z Principles of
Operation distinguish between two kinds of rounding:
  Format-constrained rounding  (most operations)
  Function-contrained rounding (LOAD FP INTEGER, QUANTIZE)

Perhaps it is the lack of this clear distinction in 754R that
leads to confusion.  I'm not arguing that we should make this
distinction explicit, as a simple addition to 7.6 would be
sufficient, as I had proposed in my draft 1.6.0 comments.

Michel.
Sent: 2008-03-16 22:30:46 UTC