[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Comments on draft 1.2 of 17 Sept 2006
(Running date still says September 12)
I use FPN and FPD to stand for floating-point number resp. f.p. datum.
Page 12, 3.2.3 and 3.2.8 (binary FPN, decimal FPN): Should be FPD,
because NaN payloads have a radix too.
(I think "3.2.10 radix" is ok in mentioning FPN and not FPD.)
Page 17, last para of 5.2, two typos: represenation, represenations
Page 36, 7.8: Several unresolved issues, some of which (e.g. Jim's
question about "supported") I thought we had dealt with,
and some which I've brought up repeatedly, namely the
rewording of Invalid handling to reflect the changes
in 9.2 that were accepted at our last full meeting.
Suggested fix: Insert (A) below before the paragraph that
mentions overflow, and insert (B) after that paragraph.
(A) When a NaN operand cannot be represented in the destination
format and this cannot otherwise be indicated, the invalid
exception shall be signalled.
(B) When a numeric operand would convert to an integer less than
zero, and the destination format is unsigned, the invalid
exception shall be signalled if this situation cannot otherwise
be indicated.
The new change (copy conversions) is fine.
Page 42, 7.12.3: Jim's clean-up motion has not been incorporated.
Page 47, 9.2 2nd para: Was the last sentence crossed out by mistake?
The bullets that follow are sentence completions, but now
there is no sentence to be completed.
Page 47, 9.2 l), logBFormat: this sentence does not read right.
How about:
l) when logBFormat is an integer format, and the operand
of logB() is a NaN, infinity, or zero (see 7.3.3).
Page 60, appendix G -- more unfinished business, going back to Aug 17
(when it was appendix F). Suitably updated, I repeat:
Page 60, last para of G.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.
Suggested replacement for 2nd sentence:
Consequently it should be possible to request that bitwise
operations like negate, abs, and copySign, which are normally
silent, should detect signalling NaNs.
Page 60, 1st para of G.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.
In fact, the next-to-last sentence says precisely that: debuggers
should be able to request that non-canonical entities be treated
like signalling NaNs. So the last sentence can simply be deleted,
as it is just plain wrong and adds nothing.
Page 60, last para of G.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.
(I bring these incompletenesses up (7.8, 7.12.3, G.3 and G.4) because
time is running out... Is there a style review tomorrow Sept 19?)
Michel.
Sent: 2006-09-18 17:12:17 UTC