[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comparisons between floats and ratios
- To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
- Subject: comparisons between floats and ratios
- From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
- Date: Mon, 27 Jan 86 11:16 EST
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12178594550.BABYL@C.CS.CMU.EDU>
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
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):
(> (condition-case ()
(float a-rational a-float)
(<overflow> (return t))
(<underflow> (return nil)))
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 >.