Hack's recirculation ballot on P754 draft 1.6.0

[Michel Hack <hack@xxxxxxxxxxxxxx>]

I thank David Hough for his comments.

> > P32 L38:  The only sensible translation-time predicate is radix().
>
> Even that is debatable: a scripting language or spreadsheet variable
> might be able to hold values in different formats, even different
> radices, that could vary at run time.  I called these "generic
> variables" in my clause10 proposed rewrite, to correspond to generic
> operations, but there probably is better terminology available.

Good point, but I did not want to imply that radix() would not be
useful as a run-time predicate.  Languages with generic types usually
have some means to distinguish types when the distinction matters.
Often the representation is as a string (or some internal format that
has a canonical string representation), and the syntax of that string
could be parsed to determine the type (if not directly available from
a field in the internal representation).

> roundToIntegralExact could be a candidate for removal on the same
> grounds as nextAfter - it's an exception to the exception model.

Perhaps, but I suspect it is useful, and already present in many
implementations.  I agree that it signals a different type of Inexact,
which David later calls "value-changing".  We can however not get rid
of quantize(), as that performs an essential function.

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.

> The bigger question with decimal is whether the important exception
> is when the decimal result is rounded, or when a decimal result
> becomes normalized and thenceforth subject to floating-point rather
> than fixed-point rules.  Here the needs of floating-point and
> fixed-point computation have been overloaded into one model of
> arithmetic.

Mike Cowlishaw's decNumber package has this, and IBM's implementation
on Systems Z9 and P6 has an instruction to test whether a DFP entity
has extreme exponent or non-zero leading digit, both of which can be
used to detect leaving the range where fixed-point rules are honoured,
as long as one gives up one digit of precision (and always combines
Divide with Quantize).  I think there was some discussion of a new IEEE
exception in the early days of the P754 Working Group, before I joined.
Presumably there was disagreement about the precise semantics, as more
than one interpretation is possible.  It is clearly too late now to do
something about it in the current standard draft.

Michel.
Sent: 2008-01-30 17:38:10 UTC