[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>*Subject*: 754R Proposed Revisions by DVJ, 14 June 2006*From*: Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>*Date*: Friday 16 Jun 2006 at 1:00 a.m. EDT (2006-06-16 05:00 GMT)*List-help*: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-754>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO STDS-754>*List-owner*: <mailto:STDS-754-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-754-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-754-unsubscribe-request@LISTSERV.IEEE.ORG>*Sender*: stds-754@xxxxxxxx

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 quantum change). 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 inexact recording. 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 Summary: We now have two proposed revisions of Chapter 5. Once agreement on substance has been achieved, will the rest be ironed out in style reviews? Michel. Sent: 2006-06-16 05:01:58 UTC

- Prev by Date:
**RE: Motion: Round to integer** - Next by Date:
**Re: [Fwd: Rejected posting to STDS-754@xxxxxxxxxxxxxxxxx]** - Previous by thread:
**RE: Motion: Round to integer** - Next by thread:
**Re: [Fwd: Rejected posting to STDS-754@xxxxxxxxxxxxxxxxx]** - Index(es):