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

Effect of Nancy="floating-point value" on 113 instances of "value"



The following applies to draft 1.1.8 of 30 August 2006.  I don't give
page numbers as different people seem to see different layouts.

Assume we adopt "floating-point value" as the technical term that
denotes whatever can be held in a floating-point variable.  How would
that affect existing uses of the word "value"?  Jim Thomas has already
shown how to deal with many instances of the word "number", and I think
we should re-examine my list of "clarifications" too, where "floating-
point number" would become "floating-point value".


Abstract: ok

Introduction: ok

Table of Contents: integral value: ok

1.4 Purpose:  ok

3.2.4 canonical encoding: representable value  ->  value (2)

3.2.4 cohort:  numerical value (ok)

3.2.7 correct rounding:  "format value" (2)   ok -- but in fact numeric

3.2.11 destination:  ok

3.2.13 exponent:  implied numeric; ok

3.2.16 floating-point number:  You have a proposed replacement.

3.2.17 format:  numerical values (ok)

3.2.21 mode:  (mode value)  ok

3.2.25 normal number:  implied numeric (ok)

3.2.27 prevailing mode:  (mode value)  ok

3.2.28 quantum:  implied numeric (ok)

5.3:   "The values of these parameters"  implied numeric (ok)
5.3:   "non-zero values"                 implied numeric (ok)

5.3:   "For any variable that has the value zero, the sign bit provides
       an extra bit of information":  PROBLEM

       A variable holds a floating-point value, and there are two
       different floating-point values that have the value zero.
       Something feels fishy here: suggest a replacement!

5.4:   "the values of the significand"   implied numeric (ok)
       "exponent value"                  implied numeric (ok)
       "values of w, bias, ..."          implied numeric (ok)

5.4    "-- The reserved value 0"     dangerous, probably ok (implied numeric)
       "-- The reserved value 2^w-1"  (talking about biased exponent)

5.4  text for 2nd bullet c), "If 1 <= E <= ..."
     text for bullet d), "If E=0 and T^=0..."
       "the corresponding representable entity value v is..."   PROBLEM (2)

      (Like signed zero above: the value of a floating-point value --
      this is not an idempotent transformation, as one might expect.)

      This entire section talks about the value v and the representation r.

      Perhaps this could be fixed by using "the numeric value of the
      corresponding representable entity".

      In fact, looking for "value" missed bullet a) in the current list
      (2nd bullet a in 5.4):  "r is qNaN or sNaN and v is NaN"

      So "v" does not necessarily mean "numeric value", but it is also
      not the same as "floating-point value", because "v" as used here
      can be the "value" of several distinct floating-point values.

      The letters r and v were introduced with:  "The floating-point
      representation r and the representable entity, v, are inferred..."

5.5 para 1:  exponent value:  implied numeric (ok)

5.5 1st bullet b):  value of 1st 2 bits:  implied numeric (ok)

Figure 5.2 caption:  implied numeric (ok)

5.5    "values of w, bias, ..."          implied numeric (ok)

5.5 2nd bullet a):  maximum value:  implied numeric (ok)
5.5 2nd bullet b):  values of the remaining bits:  implied numeric (ok)
       (8 more instances of implied numeric value)

6.1   10 instances of mode value (ok)

(50 instances so far, 3 problematic)

7.3.2 description of
   quantize(x,y)):  the result "is a number in the same format which
                    has the same value as x and the same quantum as y."
   PROBLEM (2):  again talking about the value of a floating-point value.

   I had suggested a replacement that restricted this sentence to finite
   numeric operands, as Inf and NaNs are treated separately here, but I'm
   not sure that would help.

7.3.3 logBFormat(): integral value  (ok) (2 instances)
                    language-defined values outside the range
                       implied numeric (ok)

7.3.3 scaleB():     integral value  (ok)

7.4.1 formatOf-convert():  integral value, plus two instances
                           where this qualifier is implied:  ok (3)

7.5.2 re-encoding:  ok -- and here "value" is NOT necessarily numeric;
                    in fact, it really does correspond to what is called
                    "representable entity v" in 5.5 above.  (2 instances)

7.7   (13 instances of mode values, ok)

7.8 para 1:  integral values, 2nd one implicit:  ok (2)

7.8 para 3 and 4:  floating-point value (2) and operand value (1).
      (I see a problem here, because this does in fact refer to the
      numeric value of the floating-point value.  The fix should
      however be easy enough.)

7.8 bullets:  integral value (ok)  (10)

7.9           integral value (ok)  (9)

7.12.13  3rd-last para:  implied numeric, but implication is subtle.  (4)

7.12.13  2nd-last para:  "result format's values" of an external
                                                  representation (ok),
                          "source value": implied numeric, but subtle.

8.2.2   implied numeric (ok)

B.1 3rd para:  "preserve the values of the operands".  Ought to be clear
               here: in fact, it should mean "floating-point values", as
               signs of zeros etc. matter.  I count this as (ok). (2)

B.3. 1st para:  "result value", "stored value":  inclusive meaning (ok) (2)
B.3. 3rd para:  return values, inclusive meaning (ok) (2)

E.2  values of variables:  ok

F.3  numerical value:  ok

(Grand total: 113, of which 5 major and 3 minor problems; rest ok)
Sent: 2006-09-06 21:03:59 UTC

754 | revision | FAQ | references | list archive