# Re: Rational Infinity

• To: ELIOT%cs.umass.edu@relay.cs.NET
• Subject: Re: Rational Infinity
• From: Jeff Barnett <jbarnett@NRTC.ARPA>
• Date: Tue, 3 Feb 87 19:08:31 PST
• Cc: common-lisp@sail.stanford.EDU

```I think it is very interesting that you find that traping division by zero
helps find some very obscure bugs.  It's probably also true that you think
it is easier to prove and disprove various things about your programs via
an appeal to formal mathematical models of numbers.  Why this is interesting
is that in the old days, I made the same comments when LISP systems quit
traping when we took CAR and CDR of NIL!  When they did, it helped me find
obscure bugs and I was able to prove and disprove things about my programs
via an appeal to formal mathematical models of S-EXPRESSIONS.  I gave up this
line of argument because nobody would listen and I got old an lazy a came
out of the closet and had to admit I liked using what I still consider to
be an atrocious hack.
it's a great thing.  I think that it would be sad to not make them part of the
CL standard--if you think standards are a reasonable venture, they why not
include a very good (and very well thought out) one in another.  Let me
change the word sad to foolish.  Numerical calculations that must deal with
ideal points are hard to code period.  There is no similarity in code that
uses IEEE standard and that which doesn't.  If its available, it's too good
to not use.  Insisting on the standard would force some implementors to
do extra work I know.  But I think it would be a good idea.
One of the nice things about LISP and its derivitives is that it
makes it easy and possible to code our ideas and models rather than do
everything by total hackery.  Hell, even a poor man can pretend to be a
scholar instead of a code jockey.  If you don't think the IEEE standard
solves an important problem, try coding some floating point computations
and, before you do each operation, determine (1) if this operation will
over (underflow) the size of this machines representation and (2) if any
previous operation ran into trouble, what to do in lieu of this one.
I think one iteration of this will make you kiss the IEEE standards with
ideal points.  For the record, my coding experience using hardware or
software where it was available has convinced that it reduces the coding
by a factor of 20 in routines where I cared about these things.

Jeff

```