Re: Hack's recirculation ballot on P754 draft 1.6.0

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

> General    5.7.2 
> 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. 

> Technical  7.6
> P46 L25+: The definition of Inexact on lines 22-24 does not cover
>           quantize() and roundToIntegralExact(), whose result would
>           be unchanged were both exponent range and precision unbounded.

roundToIntegralExact could be a candidate for removal on the same
grounds as nextAfter - it's an exception to the exception model.
quantize is also like nextAfter in that it is an operation that only makes
sense in a specific floating-point format and has no analog in arithmetic
on real numbers, and so its exception semantics are somewhat overloaded onto the
real arithmetic exceptions.     In principle, "value-changing conversion
to integral" and "value-changing quantization" are subexceptions of inexact,
in the same way that invalid has subexceptions.

The bigger question with decimal is whether the important exception is 
when the a 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.

> |           I would really like to know what the intent of the BRC
> |           was on some of these issues, so I know whether to make
> |           an Editorial or a Technical comment.

The most important point is that while 
the scaled product reductions are intended
and optimized for a particular type of application (ratios of big products
e.g. Clebsch-Gordan coefficients) and intended to replace the
scaled overflow/underflow traps of 754 (and were once a section under
alternate exception handling)...
 
the unscaled sum reductions are intended and optimized for something else;
I don't know what.

> | (3)  Either Infinity or NaN prevails, depending on the operation.
> |      (There seems to be a precedent with the hypot() function.  Should
> |      that be revised, these sum reductions should be revised too.)

Disappearing NaNs always generate controversy.