[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 82 comment, your reply and number crunching
- To: Brian G. Milnes <Milnes at CMU-20C at MIT-MC>
- Subject: Issue 82 comment, your reply and number crunching
- From: MOON at SCRC-TENEX
- Date: Thu, 30 Sep 1982 19:52:00 -0000
- Cc: fahlman at CMU-20C at MIT-MC, steele at CMU-20C at MIT-MC, wholey at CMU-20C at MIT-MC, common-lisp at sail, rlb at SCRC-TENEX
- In-reply-to: The message of 30 Sep 1982 14:59-EDT from Brian G. Milnes <Milnes at CMU-20C at MIT-MC>
Your point boils down to this, if I understand it:
Different floating point formats may have not only different precisions, but
also different exponent ranges. You don't care about the precision, but only
want the smallest floating point format that has enough exponent range to hold
the number you're floating.
I see a couple problems with this. One is that you have to decide somehow
which format is the smallest you use. If you have an integer that you are
floating which is small enough that it would fit in the tiniest
floating-point format (say it's 1), you don't want FLOAT to use that format
because then the precision would be too small. FLOAT has to extend upwards,
but not downwards.
The other is that you are assuming automatic conversion to larger formats, with
more exponent range, on overflow or underflow by all floating-point arithmetic
operations. Just putting it in FLOAT is no good; you might FLOAT a number that
barely fits, then add 1 to it and get an overflow. I'm not sure whether all
Common Lisp implementations want to commit to this.
I have no vested interest in precision, by the way, and am not a big user
of floating-point numbers, just an implementor. I have learned enough
about it to be feel concern for trying to keep Common Lisp away from some
known pitfalls.
It sounds like more discussion by more people is called for.