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

motion addressing the need for consistency in distinguishing between numbers and NaNs



Is there a revised document that shows how this motion is to be carried
out?  Is there even a plan on how to resolve the new ambiguity that is
introduced by the word "value", which in the current document is used
in distinction to "representation"?  Take for example 3.2.4: "...more
than one encoding for that representable value".  In some contexts the
combination "numerical value" is used.  Indeed, a show of good faith
would at least offer a rewording of 3.2.16 "floating-point number",
which is the current term that encompasses all, including NaNs, when
otherwise unqualified -- though there are indeed cases where FPN (I'm
lazy and will use this stand-in here) is used, unqualified, in a context
that refers to its numerical value -- a context which, I submit, would
be clear to most readers.  Qualifications are indeed tricky: non-zero
FPN and finite FPN imply numeric, but decimal FPN and binary FPN do not.

In fact, out of 22 mentions of FPN there is only one that is unqualified
and yet implies numeric: the monotonicity statement for conversions, near
the end of 7.12.3.

(During this search I noticed that 3.2.13 "exponent" has a strike-out
for the word "normally" in "that normally signifies the integer power".
I think this was wrong:  "normally" was precisely intended to exclude
NaNs and Inf, which have no exponent.)

The term "value" by itself occurs soooo many times that it would be a
nightmare to figure out what to replace it with, as it almost always
refers to numerical value.  So I find it difficult to believe that the
motion is to use the word "value" to denote the union of NaNs and
numeric entities.  Perhaps "floating-point value" FPV) was intended,
which qualifies "value" in the same sense that "number" is currently
qualified?  That would at least make sense, and the phrase FPV occurs
only twice in the current document, both in 7.8 (float->int conversion),
where it means "numeric value after rounding" (clearly excluding NaNs).
So there would only be these two places that need fixing.

Btw, I just realised that 7.8 does not mention *anything* about what
happens with NaN arguments!  (Dave James' tables to the rescue?)
(Never mind the lack of description of negative->unsigned conversion,
which exists only in 9.2j in the Aug30 draft.)

So what I see here is not a motion, but merely wishful thinking.
I agree with the intent of the motion, but I'm afraid the actual
proposition does not work.

Michel.

P.S.  Sorry, but I could not attend today's style review.
Sent: 2006-09-05 22:12:21 UTC

754 | revision | FAQ | references | list archive