Issue 82 of the last CL meeting

[MOON at SCRC-TENEX]

    Date: Wednesday, 29 September 1982  19:01-EDT
    From: Brian G. Milnes <Milnes at CMU-20C>

    	Issue 82 of the last common lisp committe meeting states that :
    one argument float should always return a single-float. 
This was to fix the previous travesty, where FLOAT could return a number of
smaller precision than expected, if you happened to hand it an integer with
only a few bits on (such as a power of two), since it would fit exactly.  Then
if you took the square root of that (for example), you would get a result
with less precision than you expected.

    	This is not orthogonal with the rest of the numeric functions, because
    although the default float result type is that of the most precise argument
    overflows from one float format roll onto the float format of the next greater
    precision.
This is not the way I read the bottom paragraph on page 117 of the 29July Colander
edition, which is the only thing I can find in a quick search that might be
relevant to this.

I think it is probably best for the system to do as few behind your back
"smart", "helpful" tricks in the area of floating point numbers as possible.
Certainly the 2 or 3 books on the subject I have seen are against this sort
of thing.  On the other hand, the proposed IEEE standard has some hand waving
in it that seems to be aimed at providing for switching to an alternate number
representation when overflow occurs.

I don't have an expert opinion about this, but my uninformed opinion is
that it would be better to signal exponent overflow than to switch to a
bigger number representation.  I -am- certain that it is better to signal
inexact result than to switch to a bigger number representation (in the
proposed IEEE standard, inexact result is the usually-disabled exception
that is signalled when low-order bits of the fraction are lost.)

    	If the user wants float to return only single-float, and cause an error
    if the argument will not fit can't he simple use (float x 0.0s0) ? But, if the
    user wants to return any convenient float, but not overflow or get bogged down
    in a high precision shouldn't he be able to do this with single argument float
This is a tough one.  Certainly it sounds plausible that FLOAT should work
rather than giving you an error.  On the other hand, in many implementations
the floating-point number format with the biggest precision and range is
substantially more expensive than the "standard one", so it may not be a good
idea to use it unexpectedly, and it certainly is not a good idea to make FLOAT
use it all the time.

Whatever FLOAT does, READ should do the same thing for floating-point number
syntaxes that don't explicitly specify a float type (e.g. ones with no exponent
or an E exponent).

If I have to vote, I will vote for leaving FLOAT the way it is: i.e. it always
returns "single" format.  By the way, 0.0s0 is "short" format, not "single" format.
See page 18 of the colander.