754R Proposed Revisions by DVJ, 14 June 2006
You put a lot of effort into that document, David. I like many of the
clarifications, but in a few cases I think you snipped essential details.
I read most of it in detail, but skimmed the many arithmetic tables for
mostly mundane functions -- I basically assumed you got it right.
Page 24, 4.2 Rounding direction modes
Is this section intentionally informal? If not, the round-to-nearest
definitions are incorrect (they only describe ties).
I also fail to see any requirements. Would an implementation
that offers only one mode be conforming?
Finally, the distinction between binary and decimal modes is
not mentioned. (More on that below.)
Page 29, near bottom: get-rounding-mode() may need an argument,
to specify whether the binary or the decimal mode is requested.
(The set of available modes, and possibly the default rounding
mode, may be radix-dependent.)
(To some extent this depends on whether Ron Smith's motion #34 passes.)
test-rounding-mode() needs an operand -- I assume this tests
whether the specified direction is in effect or not. This is
the first time I saw this -- who asked for this?
(You have a TBD on this on page 31.)
Page 30, near top: default-rounding-mode() needs the same argument.
For set-rounding-mode() the type (BFP or DFP) might be encoded
in the rounding-type; if not, a second argument is needed.
Alternatively, two separate functions of each of the types
discussed here are needed: get-?FP-rounding-mode() etc. (DFP or BFP)
Page 39, scaled product: Nice job. It answers some of my questions.
I suppose both widening and narrowing forms are useful; the former
during the body of a reduction, the latter at the end.
Page 42, scalb() row 3: zero values remain unchanged, but that is
not enough. The sign does not change, but (for decimal) the
representation may change, because of exponent change (and hence
Page 49, convert to signed. I assume the descriptions of max, wax
and min in terms of powers of two are just meant as examples,
because this depends on the encoding. Yes, most machines today
use fixed-width twos complement, but... some formats might not
have a max (and would rather raise an exception), but might have
suitable Inf and NaN!
I think the best you can do is to require that languages or
implementations document clearly what the behaviour is for
overflow, Inf and NaN, and suggest what they might do in the
common case of fixed-width binary.
Page 50, inexact-signaling of the above: Is this necessary or useful?
If inexact signaling is desired, one can first convert to integral
floating-point (with signaling, if desired), then to integer.
Page 51, convert to unsigned. What is "top0" in rows 1 and 2, last column?
I happen to strongly disagree with the rather common interpretation of
treating this as if converting to signed int and then casting that to
unsigned. It seems to me that the nearest representable unsigned value
for a negative argument (even -Inf) is simply Zero -- and that "floor"
cannot be applied in its "round-to-negative" sense, of returning a value
no greater than the argument (since there is none). I would argue that
this should raise an exception if possible, and that the default result
should still be zero. (This may need a separate motion...)
Btw, there has been an intermittent debate on this on usenet, in
sci.math.arithmetic, thread "unsigned arithmetic".
Page 52: same deal with respect to page 51, as 50 vs 49 above.
Page 53: Convert between different widths *and/or radices*.
At first I thought radix conversion (among internal formats) had been
forgotten, but it was quietly hiding here.
If Ron Smith's motion #34 (which I strongly support) passes, something
will have to be said about which rounding mode applies by default,
source or target. (I would prefer target radix mode.)
Some implementations may support narrowing conversions with explicit
rounding modes (of which one special value simply means "current mode");
this would also be appropriate for radix conversions. I agree however
that the standard should not require this.
Page 53, conversion between encodings: I prefer the alternative proposed
by motion #33 proposed by Jim Thomas.
Page 64, Precise-value rounding: scaleprodsum and scaleproddiff do not
belong here; Eric's new dyadic scaleprod does. The reduction operations
are (necessarily) exempt from correct-rounding requirements and proper
Page 69, table 5.40 row 12: "never" have an exception for converting
finite numbers from external to internal format? What about overflow
and underflow? In fact, on page 71 (just above the middle) it clearly
states that exception handling of subclause 7 applies.
There is also a missing row 20, for string "garbage", which might raise
Invalid and return a NaN. (Some implementations may hide this case by
suppressing assignment, but scanf() is not the only way to behave.)
Page 70, 5.6.3, line 1: Conversion parameters M and N are based on the
widest internal *basic* format. This used to be critical; the relaxed
conversion requirements of the 1985 standard were premised on the
availability of an extended format for intermediate results. It could
also be an issue when other specialised formats are supported, such as
IBM's old 1312-bit high-accuracy format.
Btw, I apologise for those upper-case SHALLs; I should have edited that
before the text was integrated...
Page 74, Infinity arithmetic: Invalid exceptions are possible for all four
basic arithmetic operations, not just division (e.g. 0*inf, inf-inf), and
hence also for fma.
Pages 77&78: Why discard all the details? The summary descriptions
at the end of page 76 are really incomplete.
I think I know what you were thinking: the details are all in the
preceding tables. Well, at least that much should be said here!
Typos & style:
Page 24: Cope -> Scope i which -> in which
Page 31, "Row 34": as a aid -> as an aid
Page 65, line 1 of "Tiny-value rounding: I assume "5.4.8" is meant
to refer to row 12 of table 5.37 on the preceding page, and
not to fused-multiply-add (this threw me for a loop until
I figured it out!!).
Page 76, 2nd para, line 2: nly -> only
We now have two proposed revisions of Chapter 5. Once agreement on
substance has been achieved, will the rest be ironed out in style
Sent: 2006-06-16 05:01:58 UTC