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

Rounding on output



    Date: Thursday, 16 June 1983, 17:02-EDT
    From: Kent M. Pitman <kmp at MIT-MC>
    With one exception, I have no special opinions about rounding on output
    and will take whatever is given. The exception is that the rounding 
    should be defined to always produce a valid number, even if in some cases
    that means violating the normal rounding rule once in a while. In Maclisp,
    the largest flonum (octal 377777,,777777) can be typed in by 1.70141182e+38
    but will type out as 1.70141183e+38, which cannot be re-read because it gives 
    a numeric overflow error. I can't decide if this is relevant to ~G, etc. or
    just to general PRIN1, but figured this was as good a time as any to mention
    it...

This problem is only vaguely related to "rounding".  The real thing you
are asking for (which is not true of most reader/printer pairs) is that
the (read (print .)) be an identity.  Most readers and printers are
sloppy about that, especially for exponents of large magnitude.  The
current Lisp Machine reader is very sloppy.

I think that the "valid number" requirement is in fact wrong.  If I ask
for your largest flonum to be printed to only one decimal place, I would
certainly like to see 2.e+38, even though that is not a valid number.
But invalid numbers should only occur when I specify the length of the
printed result.

So the correct wording of your requirement is something like:

"The (binary) floating-point value read shall be closer to the decimal
value than any other floating-point value of the same length."

"The decimal value printed shall be closer to the (binary)
floating-point value than it is to any other representable
floating-point value of the same length."  [Although that doesn't
exactly rule out printing decimal values beyond the range of floats, I
don't see how to word it without getting into ULPs (units in the last
place) or other nasty stuff.  Guy??]