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

["Ferguson, Warren E" <warren.e.ferguson@xxxxxxxxx>]

Dan, correct me if I'm wrong. 

Dan proposes that we first settle on the name we give "Nancy", i.e., the
collection of numbers and NaNs, before time is expended in style review
on implementing any needed changes. I take it that Dan would support any
motion that gives a name to "Nancy", not just the one that Jim and I put
together and sent out earlier today.
 
For example, Dan's email of last last month (8/31, 9pm) indicates that
the following terms need their usage reviewed and modified/corrected as
needed, especially in light of adopting whatever term we give to
"Nancy".

                grep -i number 754r.txt | wc
                100    3553   23273

                grep -i value 754r.txt | wc
                 86    3207   20558

                grep -i entity 754r.txt | wc
                  7     221    1475

                grep -i entities 754r.txt | wc
                 12     457    3128

                grep -i representation 754r.txt | wc
                 50    1874   12353

                grep -i format 754r.txt | wc
                319    8424   58966

And yes, "value" should be "floating-point value". The intent was to
answer Dan's question: "What can be stored in a floating-point
variable". The proposed motion gives the answer: "a floating-point
variable stores a floating-point value".

I hope the above answers your last paragraph, i.e., that the proposed
motion is more than wishful thinking. Let me know otherwise.

Warren

-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx] On Behalf Of Michel
Hack (1-914-784-7648)
Sent: Monday, September 04, 2006 10:23 PM
To: stds-754; stds-754@xxxxxxxxxxx
Subject: 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