what does a number mean?

[David G. Hough]

Tim's latest comments really get to the heart of the matter: a computer
number by itself, whether in internal binary or external decimal form,
simply means itself, and in general no extra information should be 
inferred from the number itself.  Thus

	0.1000000000000000000000000000000000000000

means one tenth exactly in the absence of other information.  If you have
the additional information that it was printed out from a binary floating-point
format, under correct rounding using the default IEEE rule
you might reasonably infer that like other correctly-
rounded results the stored value

	0.1000000000000000000000000000000000000000

was obtained from an exact binary value x that satisfied

	0.09999999999999999999999999999999999999995
	<= x <=
	0.10000000000000000000000000000000000000005

This is what correctly rounded means, using the default IEEE rule.
You might conclude from this that the binary floating-point format had
somewhat more than 64 significant bits in order to contain a value in that
interval.  If you knew otherwise, then you could infer that the base
conversion was not correctly rounded.

> does it have to produce the
>
>          0.1000000000000000055511151231257827021182
>
>    or can it do the Steele/White
>
>          0.1000000000000000000000000000000000000000

No common language prints 40 significant digits for a binary floating-point number
by default, so somebody asked
for all these digits, and without other information I presume that they had
a legitimate reason for doing so.    So display the number
they had, as best you can, rather than some other number that you think they
might have had in mind.  If they wanted an output that reflected the precision
of the binary floating-point format, they would have specified some other suitable
decimal format.

> (*must* be inexact since 1./10^e isn't
> representable for any int e>0) I don't see a fast way to figure out
> whether the result lost information.

Ultimately you can't do correctly-rounded base conversion with negative
powers of ten, because ultimately you have to do integer arithmetic.
Negative powers of ten can be used effectively to speed up simple cases.

> complexity is complexity to me,
> regardless of which side of the fuzzy "implementor/user" fence it falls
> on.  If it falls on the user's side, then as a user I don't want to deal
> with it; if it falls on the implementor's side, then as a user I'd be a
> fool to trust my vendor to do it all right <grin>.

This argument was used against IEEE 754 from the beginning, and is tantamount
to arguing that because long complicated proofs are likely to contain errors,
then mathematics shouldn't contain any theorems with long complicated proofs.

Correct hypothesis, faulty assertion.  Errors in proofs may not be fatal;
simpler proofs are often found later; 
what seemed refractory to earlier generations becomes less so
with the passage of time.   In the long run, of course,
the benefit of a particular theorem
should outweigh the cost of understanding its proof!
The value of a theorem is the extent to which it allows you to know more
while remembering less.   A similar statement applies to programs!

> 1) Is it OK by NCEG if, as Sun apparently does these days, the "perfect
>    input" routine gives up on setting inexact correctly if faced with
>    more than some 512 input digits?
  
I hope not.  In the SunOS 4.0 implementation,
I put a finite limit on the input/output buffers so nobody
would have the responsibility for freeing up malloc'ed storage.  The
right way to do this would have been to use small fixed buffers (20 digits)
plus a pointer to a larger buffer allocated when needed.  This avoids
any arbitrary a-priori limit while maintaining efficiency in the normal
case.   
Coming, perhaps not as soon as I'd like, 
to a public-domain release near you...
Overcoming the fixed buffer size is something I hadn't thought about in a while, 
and shows the value of these electronic discussions, to me at least.

> My *primary* gripe here is, again, that I don't know how to answer these
> questions based on what the NCEG draft currently says.

Tim's interest is in what the current wording means, 
and if it's unclear, it should be fixed.  
My expository interest is in what it should mean, and later how to say it.