[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comparisons between floats and ratios
Date: Mon, 27 Jan 86 11:16 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Mon, 27 Jan 1986 10:37 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow? If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine.
Sounds like a job for the error system (a proposal for which KMP is
supposed to have ready soon). Better to intercept this rare overflow
problem when it occurs, and when you actually care, than to slow down
the universe by trying to prevent it.
There are two places to put the condition-case/bind (or whatever the KMP
equivalent is). One is in the application program, the other is in the
system code that does the comparision.
Putting it in the application program will look like Common Lisp has a
wart that numeric comparisons need special help sometimes.
Putting it in the system code would probably slow it down as much as
doing the check. The system code would probably look like (already
checked that both are positive):
(block nil
(> (condition-case ()
(float a-rational a-float)
(<overflow> (return t))
(<underflow> (return nil)))
a-float))
This points up a problem with putting it in the application program: If
overflow is signalled, how does the application figure out what the
intent was? It might be hard to figure out that (float a-rational a-float),
which is where the error happened, was being used for >.
Ack! Even though we have an error system, I didn't consider using it
for this particular application. I used the IEEE-required ability to
turn off overflow traps: [simplified for presentation]
(defnumop < ((x float) (y bignum))
(if (infinite x) ; + or - infinity
(minusp x)
(without-floating-overflow-traps
(< x (float y x)))))