what does a number mean?

[Tim Peters]

>  [david hough]
>  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.

Fair enough -- although once I do know what it means, *then* I'll scream
that it "shouldn't" mean that <grin>.  I think I do know exactly what
*you* mean by "perfect rounding" in the decimal<->binary context now,
and thank you for making it clear.

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

Sure it should:  the raw fact that it's a "(floating point) computer
number" should be enough all by itself to trigger every user's "danger!
approximation!" alarm.  If they really want to know the last bit, and
are too lazy <grin> to print it in hex, they're almost certainly using
the wrong tool (floating point) for the job (something where the value
of the last bit truly matters).

>  Thus
>
>  	0.1000000000000000000000000000000000000000
> 
>  means one tenth exactly in the absence of other information.

Agree that's one of several possible interpretations, and even better
than most.

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

Granting that an unusually knowledgable user *could* draw such
inferences, I don't know why they'd want to bother.  Any user *I* know
who sees

    0.1000000000000000000000000000000000000000

just says "OK, so the answer is real close to a tenth", and that's all
the info they wanted to know to begin with.  If they want to know the
precision of the machine, they ask; if they want to know whether it's
exactly a tenth, they don't use floating point to begin with.  Different
strokes, y'know?  I don't want NCEG forcing a value judgment that costs
onto people who have no use for it.

>  >    [perfect rounding to 40 places]
>  >          0.1000000000000000055511151231257827021182
>  >    [vs the 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.

Name one <grin>.

>  So display the number they had, as best you can, rather than some
>  other number that you think they might have had in mind.

To the extent that this sentence says "print something rigorously
defined (& so predictable etc) instead of making something up" I fully
agree.  What I disagree with is the implication that perfect rounding is
the only useful rigorously defined behavior.  The Steele/White behavior
is also rigorously defined, and has at least the attractive (to some of
us <smile>) advantage that it predictably runs a heck of a lot faster
when forced to print an absurd number of digits.

>  If they wanted an output that reflected the precision of the binary
>  floating-point format, they would have specified some other suitable
>  decimal format.

Ever port a large program using oodles of fixed-format output statements
to a machine with a different precision?  If so, how long <grin> before
you gave up trying to fiddle all the field widths and column headings to
"match" the new precision?

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

Thanks -- I was afraid of that.  I've written "infinite precision"
floating base converters at least five times in the past (in Lisp,
BASIC, REXX, Icon, and the HP-28S's RPL), and always stuck to simple
exact methods that didn't do anything fancier than repeatedly
multiplying/dividing a vector of digits by a single digit (faking
arithmetic in an appropriate base).  So I'm not at a loss to figure out
how to do it (and obviously found it important enough for *my* purposes
to implement more than once) -- but I am at a loss when it comes to the
"*fast*" part.  When I talk with my potential users and my employer's
applications people, I hear that a correctly-set inexact flag on
decimal<->binary conversions is worth (and I quote) "nothing" to them.
Hence an approach like Clinger's that gives up just that much is very
attractive -- but let's hear from some other 754 vendors!  KSR cheats
on the std anyway <grin/sigh>.

>  > If it [complexity] 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!

Correct hypothesis, & a pretty good argument up to the last sentence
<grin>.  How do implementations differ from proofs of theorems?  Let us
count the ways:

1) It's unusual for a difficult theorem to be tackled by anyone other
   than a true expert in the field.  It's common for implementations to
   be done by the least overburdened warm bodies of any kind (don't
   forget that you're arguing about base conversions with a compiler
   jockey <grin> -- think this is what I was *hired* for <snort>?).

2) The proof of a difficult theorem is critically scrutinized by
   independent experts all over the world.  I don't know about the other
   people on this list, but I think it's quite unlikely that, e.g.,
   Knuth or Kahan will be checking the details of *my* code and putting
   their reputations behind it one way or the other.

3) Proofs of theorems are generally published and public.
   Implementations usually aren't (e.g., Sun's, KSR's, IBM's, ...).

4) The proof of a theorem is abstract -- abstract enough that everyone
   who wants to check, extend, study, simplify or use a proof can start
   with the *same* proof.  Implementations are concrete, and generally
   change in many ways from one platform to the next.  E.g., suppose
   your PD base-conversion implementation is proved correct to
   everyone's satisfaction, and I gratefully take it for the KSR
   machine.  The second <grin> thing I'll do is totally rewrite it,
   because it's certain not to take full advantage of my architecture
   (e.g., the KSR machine can do a 64x64->128 unsigned integer multiply
   in an amazingly short time, and I'm as sure that would speed things
   up as I am that your PD code will have to be rewritten to exploit
   it).  Every change I make can introduce an error, and nobody will
   check it except for me.  My users *would* be fools to rely on me
   getting it all right; that *you* got it all right won't help them,
   because they're not using your "proof".

This could go on for a long time ... think it's really just sketching
the differences between public science and proprietary engineering.  I'm
an engineer (actually more like a janitor <0.7 grin>), and have the
engineer's intrinsic bone-deep mistrust of not-for-a-clear-purpose
complexity in any part of the system -- and also the engineer's
willingness to say "OK, close enough for what the customers say they
want -- so let's move on to the next nightmare <smile>".

>  I hope not [that NCEG will bless ignoring digits after the 512th].
>  ...  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 ...  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.

I too get the least from this list when reading contributions like the
one I'm writing <blush> and the most from "now here's an approach!"
thought pieces like yours above.  If NCEG agrees not to *mandate*
perfection in this area (beyond what 754/854 requires), I bet
contentious msgs like this one will cease (wouldn't do any good if just
I shut up, 'cause a thousand would arise to take my place).

ok-maybe-one-or-two<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
timaksr.com,  ksr!timaharvard.harvard.edu