[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
More comments on draft 1.1.5 (Aug15) for Aug17 style review
Continuing on page 45, Chapter 9... (see yesterday's post for pages 1-44).
Page 45, 4th para from bottom, line 2: at most only two -> at most two
Page 45, 4th para from bottom, line 3: followed -> with or followed
(two instances)
Page 45, 3rd para from bottom, line 3: remove "might be signaled"
(Am I misunderstanding something? Under what circumstances would
Inexact NOT be signalled during DEFAULT underflow handling?)
Page 49, B.1 Overview, line 1: remove 1st comma (after Clause 7)
Page 49, B.1 Overview, line 2: raising -> raise
Page 49, B.1 Overview, 3rd para, line 3: super set -> superset
Page 51, Annex C, 2nd bullet (Widento format modes), line 5:
Insert "shows" or "lists" after "Table C.1"
Page 52, Table C.1 -- Widento operations, several comments:
(a) Editorial question. The predicates need not be listed,
as widento would not affect the result.
(b) For the same reason, the minNum etc. operations need not
be listed, except perhaps when the destination is widened
as a result -- but assignment would coerce the result back
to the target format, and for an intermediate result the
widento of the next operation would prevail.
(3) Perhaps the functions of D.1 could be included simply
by reference, instead of repeating the list and risking
getting out of synch.
Page 54, bottom, restored atan() notes (next-to-last para on page):
We could be explicit: Binary32 and Decimal64 would be
rounded the wrong way; Binary64, Binary128 and Decimal128
would be rounded correctly (if supported).
Page 55, E.1 Overview, 3rd bullet: remove the mention of a macro
Page 55, E.2 Overview, 1st para line 3: insert "or" after "Languages"
Page 56, E.4 Scaled-product, 1st para last line: scalb -> scaleB
Page 56, E.4 Scaled-product, all bullets: use camelcase: scaledProd,
scaledProdSum, scaledProdDiff.
Page 58, last para of F.3 Numerical Exceptions. I don't know what
to make of this: it recommends that that the bitwise operations
violate the standard. (At least old 754 allowed those functions
to be signalling.) Perhaps this is recommending that there be a
directive to select alternate functions, explicitly for the purpose
of debugging -- but then it should say so.
Page 58, 1st para of F.4 Programming errors, last sentence should be
removed: The behaviour for non-canonical forms is NOT left up
to languages or implementations, it is fully defined by this
standard. Again, perhaps the suggestion is that there be a way
to run a program with explicit canonicity checks at any point
where data enter a scope.
Page 58, last para of F.4 Programming errors (and last of document).
The issue of NaNs "pointing to" something comes up again and again,
and yet there are a number of things that stand in the way. The only
kind of information that can reliably travel in quiet NaNs is small
integers, encoded bit-reversed in binary NaN payloads. It is true
that signalling NaNs can in principle carry arbitrary information,
but only when trapped (non-default handling of Invalid). This may
be sufficient for the purposes here, but it raises other issues, at
least in the context most of you operate in: high-level languages.
It requires that the program's default handling be turned off, and
that resumable traps into the debugger be supported. I know how to
do this (and have done so) with low-level debuggers that operate at
the assembly-language level, but it is difficult unless the whole
programming environment is structured to support this.
See (hear) you in an hour or so...
Michel.
Sent: 2006-08-17 16:47:40 UTC