[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
P754-150 comments
I offer here a preview of the comments I plan to submit to the IEEE ballot.
I will follow up with some technical points for discussion.
In general, the document has been improved quite significantly. Essentially
all my concerns voiced during the previous ballot have been addressed to my
satisfaction, even some that a few months ago I thought had fallen between
the cracks in the floor.
I still have some disagreements with the controversial new section on
reproducibility, but I'm glad to see that my main point has been addressed,
namely pointing out explicitly that reproducibility requires cooperation
from the programmer. I'll give some technical details on the fma() and
underflow issues in a subsequent posting.
Michel
*----------------*
Editorial 18 3.5 17
Typo: arithmetic operands -> arithmetic operations
Editorial 19 3.5 14
See line 38 -- in binary encoding, "digit" is misleading, as
the three or four bits derived from the combination field do
not correspond to a digit.
Change digit -> digit or bits
Editorial 23 4.2 23
The terminology "dynamic-mode variable" is dangerous, as it may
suggest that the mode could be carried in a program variable so
declared. In fact, the changes to this "variable" must be explicit
as explained on line 29.
I have no good suggestion. I thought of "entity" but that's not
very enlightening either.
Editorial 27 5.3.1 22
copySign() needs a forward reference
Add "(See 5.5.1)"
Technical 34 5.7.4 30
Description looks incomplete, unless accompanied by a restriction
on the need for matching exceptionGroupType operands. Without
this, are there any requirements on the composition of groups,
as in: testSavedFlags(saveFlags(group1), group2) ???
Either state that this is undefined if group1 differs from group2,
or define it, e.g. that this behaves like having used a common
group that is the intersection (in terms of flag sets) of group1
and group2.
Technical 37 5.10 26
Payload ordering is not defined, at least not for binary formats.
For decimal formats, the payload is defined as an integer as
encoded by the trailing significand, but for binary formats it
is not entirely clear, as there are two possible interpretations,
especially in the context of conversions between formats that are
expected to preserve at least some payloads. If a common view of
payloads is that of bounded unsigned integers, with sufficiently
small values expected to survive format conversions, then binary
payloads are likely interpreted as encoded bit-reversed.
I have no good suggestion here. I suspect totalOrder() is
intended to be reasonably efficient, and may well use a different
interpretation of payload than the one used in format conversions.
Editorial 42 5.12.2 9
Formatting glitch? Looks like the last word on the line ("an")
is crossed out.
Fix formatting.
Editorial 43 5.12.3 13
Missing "?" at the end, assuming hexExponent is still optional.
Add missing "?".
Editorial 43 5.12.3 32
Typo: The subject of "and signals" is plural ("conversions").
Change to "and signal"
Technical 43 5.12.3 33
Assuming the missing "?" on line 13 was intentional, the NOTE
should mention that, unlike C99, the hexExponent component is
mandatory.
Resolve the conflict between lines 13 and 33.
Editorial 45 6.2.1 4
Be clear about how precisely the payload is defined, given the
issue with totalOrder() on page 37 line 26.
Replace "is the p-2 ..." with "is encoded in the p-2 ...".
Editorial 45 6.2.2 10
Be clear about how precisely the payload is defined, given the
issue with totalOrder() on page 37 line 26.
Add "as defined in 3.5 item a)", or perhaps rephrase: "is the
integer encoded in the trailing significand field".
Editorial 49 8.1 9
The Invalid exception might be a better candidate than
divideByZero for having subcases. For example, the PowerPC
architecture defines several subclasses. Are there examples
of multiple divideByZero cases, perhaps in software, e.g. to
distinguish logB() from plain division?
Replace "divideByZero" with "invalid" -- or leave alone. I
admit that "invalid", being a plain English word, would not
stand out as well.
Editorial 60 11 29
The "literal meaning" should be qualified, as an unqualified
interpretation could imply that short-circuiting of logical
expression evaluation (which is significant in the presence
of side-effects) is not allowed.
Add "(as defined by the language)" after "literal meaning".
Technical 60 11 30
This fma() behaviour only matters in the presence of NaNs. There
are *many* situations involving NaNs than can lead to differences
between conforming platforms -- unless this clause proposes fully
to define NaN propagation rules, including NaN signs. Otherwise
uses of otherwise-reproducible operations like isSigned() and
totalOrder() can lead to non-reproducible results in the presence
of NaNs. It would therefore be more useful to add a section on
how to avoid reproducibility issues due to NaNs.
It is also expensive to provide the preferred fma() behaviour on
platforms whose native fma() works the other way -- for essentially
no net gain in reproducibility. (Look for details on the stds-754
e-mail reflector.)
Remove this conformance requirement on fma().
Technical 60 11 32
Why would binary underflow deliberately be defined to use the
opposite tininess detection rule than the one for decimal? It
is expensive to cover up the native behaviour when it conflicts,
for very little gain. Programs that check for underflow can be
written to cover up the difference by checking the result, and
ignoring the underflow when the result is Nmin. Effectively this
does implement the suggested behaviour -- but in a context where
the side-effects on flags are visible and hence controllable.
The problem with mandating this behaviour at the primitive level
is that side-effects of remediation have to be covered up, or they
would present their own implementation-dependent variability. Such
coverup is unreasonably expensive however, as it would have to be
performed for every operation, just in case it might matter (when
in fact it almost never will).
Remove this conformance requirement on binary tininess detection.
Technical 60 11 47
Several additional points should be mentioned:
(a) Avoiding dependence on NaN propagation and sign rules.
(b) Avoiding dependence on representation (such as overlaying
one datum type over another, a common practice is so-called
bit-twiddling programs).
To these should be added avoidance suggestions for the two cases of
misguided conformance requirements that should be dropped, though
one of them (fma() behaviour) actually falls under (a) already.
Specific suggestion: Add the following bullets.
- avoiding dependence on NaN propagation and sign rules
- avoiding dependence on representation (e.g. type overlays)
- being aware of the subtle fma() issue with regard to NaN
- being aware of the tininess detection issue for binary formats
Sent: 2007-10-13 21:34:19 UTC