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

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
   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


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

754 | revision | FAQ | references | list archive