Comments on David Hough's proposed ballot submissions

[Michel Hack <hack@xxxxxxxxxxxxxx>]

I note that some of the points I raised are also covered by David's
proposals; I'll point them out as I go along.

Formats (3)
-----------

Takes care of my P32 L24 objection that isCanonical() and isSignalling()
need to be supported for non-arithmetic interchange formats.

Also explicitly says that a basic format might be supported only for
interchange, and not for arithmetic.  I thought that this was not
entirely clear in draft 1.6.0 as I read it.

I agree with David that it may be premature to nail down future wide
formats, but not strongly; I do understand the desire to pre-empt
unnecessary variation.

Flags (5.7.4)
-------------

In David's overview (ballot5.html) he mentions my P33 L23 concern about
mismatching flag groups in restoreFlags() and saveFlags().

I like the more precise definition of the flagGroupImage type.

I don't understand the purple prose after the raiseFlags() description.

I agree that explicit functions for groups ALL and each of the five
INDIVIDUAL flags should be defined; after all, that's precisely what
all earlier drafts had called for (while the Working Group was active).

Recommended operations (9)
--------------------------

A lot of work went into drafts 1.5.x and 1.6.0 for the specification
of special-value behaviour by means of limits, but I wonder if David's
simpler presentation might not be more effective.  In the days when we
had purple-prose annotations, that would have been the place for those
justifications by limits.  Perhaps a short appendix might still be
useful.

I also agree with more decoupling of P754 names from names actually
used in programming languages, so that it becomes a language's
responsibility for mapping a pow() function onto pown() or powr()
as defined by that language, possibly with guards for special cases,
and also whether trig functions use radians or some other "unit".

Expression Evaluation (10)
--------------------------

I like the clarification, and the definition of the minWidth concept as
opposed to the widenTo concept.  I don't know the history of the widenTo
concept; it was new to me when I first heard the term, though I was
familiar with the old K&R rule for C, which was in fact in terms of
widening input arguments, and not about narrowing precise intermediate
results.

The names minWidth_nobinary and minWidth_nodecimal are really bizarre
however; noMinWidthBinary might have been better.  But do we need this
concept at all?  Would minWidth_binary32 (where binary32 would be the
narrowest supported basic format) not be just as good?

I also agree with dropping comparisons from the operations affected
by minWidth, or widenTo as it is (imperfectly, perhaps) defined in
draft 1.6.0 -- indeed, comparisons can be affected only by widening of
input arguments (as in K&R C), and not by the current interpretation.
(The fact that comparisons WERE listed contributed to my earlier
misunderstanding.)

This section also takes care of my P57 L37 comment about noWidenTo.

Michel.
Sent: 2008-01-29 20:00:52 UTC