I start learning lisp and I am using GNU CLISP 2.32
I am now trying some very simple example from a test book,
but somehow clisp give me a strange result. adding 3.13 and 2.71 should
produce 5.85, but somehow it returns 5.850004. Any comment on this?
By the way, I have a mac. Do you know any good lisp freeware on the mac
platform?
Thanks,
Anthony
STACK depth: 16367
GNU CLISP 2.32 (2003-12-29) (built on dirac.cgtp.duke.edu [152.3.25.193])
Software: GNU C 3.3 20030304 (Apple Computer, Inc. build 1640) ANSI C
program
Features [SAFETY=3]:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER
CLISP-DEBUG SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN
UNICODE BASE-CHAR=CHARACTER UNIX)
Installation directory: /sw/lib/clisp/
User language: ENGLISH
Machine: POWER MACINTOSH(POWER MACINTOSH)powerg4.local [192.168.0.3]
PowerG4:~ apang$ clisp
STACK depth: 16367
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2003
[1]> (+ 3.14 2.71)
5.8500004
[2]>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Anthony Pang wrote:
> I start learning lisp and I am using GNU CLISP 2.32
> I am now trying some very simple example from a test book,
> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>
Your computer is broken. 3.13 + 2.71 = 5.84
> Anthony Pang wrote:
>
>> I start learning lisp and I am using GNU CLISP 2.32
>> I am now trying some very simple example from a test book,
>> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>
OK, I'll play nice. This question was discussed recently:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th=de025b20bbc9cd6d&seekm=86ekkmnkk6.fsf%40goldenaxe.localnet#link9
David Sletten escreveu:
>
>> Anthony Pang wrote:
>>
>>> I start learning lisp and I am using GNU CLISP 2.32
>>> I am now trying some very simple example from a test book,
>>> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
>>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>>
> OK, I'll play nice.
After imposing seven minutes of anger to the OP. You're a recovering to
get nice!
ROTFL
> This question was discussed recently:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th=de025b20bbc9cd6d&seekm=86ekkmnkk6.fsf%40goldenaxe.localnet#link9
>
David Sletten escreveu:
> Anthony Pang wrote:
>
>> I start learning lisp and I am using GNU CLISP 2.32
>> I am now trying some very simple example from a test book,
>> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>
> Your computer is broken. 3.13 + 2.71 = 5.84
David, is your calendar broken? Today is not April first!
LOL
["Anthony Pang" <···········@gmail.com>, Mon, 18 Oct 2004 13:17:17 -0600]:
> adding 3.13 and 2.71 should produce 5.85, but somehow it returns
> 5.850004.
s/3.13/3.14/
"What Every Computer Scientist Should Know About Floating-Point
Arithmetic"
<http://docs.sun.com/source/806-3568/ncg_goldberg.html>
If that is a problem for your application, don't use floats:
CL-USER> (+ 313/100 271/100)
117/20
CL-USER> (coerce * 'double-float)
5.85d0
Albert.
Anthony Pang wrote:
> I start learning lisp and I am using GNU CLISP 2.32
> I am now trying some very simple example from a test book,
> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>
> By the way, I have a mac. Do you know any good lisp freeware on the mac
> platform?
Depends on what you mean by "free". ;) Mac OS X currently seems to be
the best-supported platform for Common Lisp. See
http://alu.cliki.net/implementation for a list of implementations, and
hppt://alu.cliki.net and http://www.cliki.net for more resources.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza escreveu:
>
> Anthony Pang wrote:
>
>> I start learning lisp and I am using GNU CLISP 2.32
>> I am now trying some very simple example from a test book,
>> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>
>> By the way, I have a mac. Do you know any good lisp freeware on the mac
>> platform?
>
>
> Depends on what you mean by "free". ;) Mac OS X currently seems to be
> the best-supported platform for Common Lisp. See
> http://alu.cliki.net/implementation for a list of implementations, and
> hppt://alu.cliki.net and http://www.cliki.net for more resources.
>
>
Pascal,
Do the 'depends' helped to avoid proposing the OP to look at the FAQ?
BTW, this question about the number 'accuracy' isn't becoming a FAQ as well?
--
Cesar Rabak
Cesar Rabak wrote:
> Pascal Costanza escreveu:
>
>>
>> Anthony Pang wrote:
>>
>>> I start learning lisp and I am using GNU CLISP 2.32
>>> I am now trying some very simple example from a test book,
>>> but somehow clisp give me a strange result. adding 3.13 and 2.71 should
>>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>>
>>> By the way, I have a mac. Do you know any good lisp freeware on the mac
>>> platform?
>>
>>
>>
>> Depends on what you mean by "free". ;) Mac OS X currently seems to be
>> the best-supported platform for Common Lisp. See
>> http://alu.cliki.net/implementation for a list of implementations, and
>> hppt://alu.cliki.net and http://www.cliki.net for more resources.
>>
>>
> Pascal,
>
> Do the 'depends' helped to avoid proposing the OP to look at the FAQ?
>
> BTW, this question about the number 'accuracy' isn't becoming a FAQ as
> well?
FAQs? We don't need no stinkin FAQs. The denizens of c.l.l like helping
newbies. Most FAQs take about two seconds to answer. Less to ignore if
it bothers one that much.
A Web site has a conspicuous link to FAQs, so I always start there. Not
so for NGs, tho some auto-post a weekly article pointing to an FAQ. The
thing is, when a newby hits some surprising feature of CL, they do not
realize it is an FAQ, they think CL has gone mad. CL being so different
from the Fortran tree of languages.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Thanks for the information provided from you all.
I learnt lisp 10 years ago in my programming language class
and I didn't quite get it at that time. Since then I only use C and C++.
I read some books saying that by learning programming in lisp would help
one to think smarter. That's why I start learning lisp again.
Is there any particular reason why the default real number representation
is float instead of double in lisp? Is that just a historial reason?
Nowadays computer is quite fast. With single precision as the default
seems to be a premature optimization. It would be nice to have double
as default to avoid surprise.
Any comment on these?
On Tue, 19 Oct 2004 03:31:34 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
> Cesar Rabak wrote:
>> Pascal Costanza escreveu:
>>
>>>
>>> Anthony Pang wrote:
>>>
>>>> I start learning lisp and I am using GNU CLISP 2.32
>>>> I am now trying some very simple example from a test book,
>>>> but somehow clisp give me a strange result. adding 3.13 and 2.71
>>>> should
>>>> produce 5.85, but somehow it returns 5.850004. Any comment on this?
>>>>
>>>> By the way, I have a mac. Do you know any good lisp freeware on the
>>>> mac
>>>> platform?
>>>
>>>
>>>
>>> Depends on what you mean by "free". ;) Mac OS X currently seems to be
>>> the best-supported platform for Common Lisp. See
>>> http://alu.cliki.net/implementation for a list of implementations, and
>>> hppt://alu.cliki.net and http://www.cliki.net for more resources.
>>>
>>>
>> Pascal,
>> Do the 'depends' helped to avoid proposing the OP to look at the FAQ?
>> BTW, this question about the number 'accuracy' isn't becoming a FAQ as
>> well?
>
> FAQs? We don't need no stinkin FAQs. The denizens of c.l.l like helping
> newbies. Most FAQs take about two seconds to answer. Less to ignore if
> it bothers one that much.
>
> A Web site has a conspicuous link to FAQs, so I always start there. Not
> so for NGs, tho some auto-post a weekly article pointing to an FAQ. The
> thing is, when a newby hits some surprising feature of CL, they do not
> realize it is an FAQ, they think CL has gone mad. CL being so different
> from the Fortran tree of languages.
>
> kenny
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
"Anthony Pang" <···········@gmail.com> writes:
> Is there any particular reason why the default real number representation
> is float instead of double in lisp? Is that just a historial reason?
> Nowadays computer is quite fast. With single precision as the default
> seems to be a premature optimization. It would be nice to have double
> as default to avoid surprise.
There is no "default real number representation". Real numbers are
given representations based on how much information is given about
them. The REAL type in Lisp is a super-type of RATIONAL and FLOAT. I
believe you are speaking of numeric constants appearing in source
code, in which case the syntax dictates their representation. For
example,
(typep 1/25 'rational) => T
because you provided a numerator and a denominator.
(typep 1.0d0 'double-float) => T
because you explicitly requested DOUBLE-FLOAT.
(eval-when (:compile-toplevel :load-toplevel :execute)
(setf *read-default-float-format* 'double-float))
(typep 1.0 'double-float) => T
because I set the default float format to DOUBLE-FLOAT [1]. The
EVAL-WHEN ensures that the variable is set during compile, if this
form was in a file.
But if you are worried about ``premature optimization'' then you
should reconsider using floating-point at all. Floating-point
arithmetic is not exact, it can only approximate most real numbers,
and is not meant to be a replacement for rational arithmetic. The
fact that many languages today abuse it as such is testament to the
poor judgement of those languages' designers, not to the correctness
of such use. If you want to avoid surprising rounding errors, do not
use floating-point, use rationals instead.
[1] Section 2.1.2 CLHS,
http://www.lispworks.com/reference/HyperSpec/Body/02_ab.htm
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <··········@cmu.edu> writes:
> There is no "default real number representation".
Well, the results of transcendental functions like "sin" must return
a "single float" when applied to an integer or rational (unless the
result happens to be representible exactly).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Matthew Danish <··········@cmu.edu> writes:
> > There is no "default real number representation".
> Well, the results of transcendental functions like "sin" must return
> a "single float" when applied to an integer or rational (unless the
> result happens to be representible exactly).
There are two problems with the phrase "default real number
representation" which I did not delve into before.
* The REAL class does not include all real numbers.
* The REAL class is abstract, it is exhaustively partitioned into
disjoint sub-classes RATIONAL and FLOAT. There is no "default
REAL number representation" because there is no "REAL number
representation" in the first place.
Now, I assumed that what he meant was the default choice of
representation for numeric literals, though he was not specific about
this. The issue for transcendental functions is closely related, and
in this case I believe the appropriate way to obtain double-float
results is to supply a double-float argument (see 12.1.4.4).
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
>>>>> "Matthew" == Matthew Danish <··········@cmu.edu> writes:
Matthew> Now, I assumed that what he meant was the default choice of
Matthew> representation for numeric literals, though he was not specific about
Matthew> this. The issue for transcendental functions is closely related, and
Matthew> in this case I believe the appropriate way to obtain double-float
Matthew> results is to supply a double-float argument (see 12.1.4.4).
Yes, it's clear how to get a double-float result, but I certainly find
it annoying that an rational arg does not produce a long-float result.
My expectation is to return the best result we can for an exact arg.
I guess I need to adjust my expectations.
Ray
"Anthony Pang" <···········@gmail.com> writes:
> Is there any particular reason why the default real number representation
> is float instead of double in lisp?
It is not. The default is taken based on the read syntax of the value
and based on type contagion rules. Lisp doesn't have "float" and
"double" types, in any case.
> Is that just a historial reason?
> Nowadays computer is quite fast. With single precision as the default
> seems to be a premature optimization. It would be nice to have double
> as default to avoid surprise.
>
> Any comment on these?
Where did you come up with the misconception that single-float and
double-float specified any bit-structure or -size? A single-float could
easily be 64-bit on some implementation.
Floating point numbers will ALWAYS be imprecise. That is the WHOLE
point! (pun intended!) If they were precise, they couldn't be
implemented efficiently in hardware and would be exactly the same as
Lisp's RATIONAL type. If you want RATIONAL, please use that.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
I am a newbie to lisp so I did not aware of the rational type in the
language.
As more information is provided, the compiler/interpretor can do exactly
what
the user wants. But when insufficient information is provided, the
implementation
of compiler/interpretor provide a default setting for the missing
information.
In the case of my simple example, when lisp see 3.14, it has a choice to
store
it as a double-precision or single-precision float and it decided to store
it
as single-precision. In both cases, they are not precise. My point is that
the
default implementation may want to take the underlying hardware into
consideration.
After all, I am pretty new to lisp, I think lisp language has so much to
offer and
I want to see whether certain behaviour of the language has some hidden
meaning
or it just stay the way it was.
By the way, I notice that when I am looking/thinking in terms of lisp
syntax,
I need to think outward (from the deepest parenthesis) and by doing so
forcing
me to look at the big picture. (If we think in terms of parse tree, we look
bottom-up) This is quite different from programming in C/C++ or similar
language
in which you read code linearly (from the beginning of a procedure to the
end
line by line). This direction is also true when you write the program. And
with
so many parenthesis, it really forces user to concentrate and may be
that's why
less likely to make mistake. Is my observation correct or simply my
imagination?
Thanks!
On Tue, 19 Oct 2004 14:21:39 -0400, Rahul Jain <·····@nyct.net> wrote:
> "Anthony Pang" <···········@gmail.com> writes:
>
>> Is there any particular reason why the default real number
>> representation
>> is float instead of double in lisp?
>
> It is not. The default is taken based on the read syntax of the value
> and based on type contagion rules. Lisp doesn't have "float" and
> "double" types, in any case.
>
>> Is that just a historial reason?
>> Nowadays computer is quite fast. With single precision as the default
>> seems to be a premature optimization. It would be nice to have double
>> as default to avoid surprise.
>>
>> Any comment on these?
>
> Where did you come up with the misconception that single-float and
> double-float specified any bit-structure or -size? A single-float could
> easily be 64-bit on some implementation.
>
> Floating point numbers will ALWAYS be imprecise. That is the WHOLE
> point! (pun intended!) If they were precise, they couldn't be
> implemented efficiently in hardware and would be exactly the same as
> Lisp's RATIONAL type. If you want RATIONAL, please use that.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
"Anthony Pang" <···········@gmail.com> writes:
> I am a newbie to lisp so I did not aware of the rational type in the
> language. As more information is provided, the compiler/interpretor
> can do exactly what the user wants. But when insufficient
> information is provided, the implementation of compiler/interpretor
> provide a default setting for the missing information. In the case
> of my simple example, when lisp see 3.14, it has a choice to store
> it as a double-precision or single-precision float and it decided to
> store it as single-precision.
Hold on; single-float and double-float are not like float and double
in C. There are four float types: single-float, double-float,
short-float, and long-float. There is a certain minimum amount of
precision mandated for each, but there is no defined precision
otherwise. In fact, an implementation may choose to have only a
single float type (such as LispWorks, IIRC), in which case it only
uses single-float (and aliases the others to this) but may have the
precision of a double. So the default format for reading numeric
float literals may be single-float, but that does not mean
single-precision as in C. And, as I pointed out before, you can
change this default by a variable.
> In both cases, they are not precise. My point is that the default
> implementation may want to take the underlying hardware into
> consideration.
The whole point of having floating-point number support in Lisp is to
take advantage of the underlying hardware which is so common. Really,
floating-point numbers are a very special-purpose tool for number
crunchers.
> By the way, I notice that when I am looking/thinking in terms of
> lisp syntax, I need to think outward (from the deepest parenthesis)
> and by doing so forcing me to look at the big picture. (If we think
> in terms of parse tree, we look bottom-up) This is quite different
> from programming in C/C++ or similar language in which you read code
> linearly (from the beginning of a procedure to the end line by
> line). This direction is also true when you write the program. And
> with so many parenthesis, it really forces user to concentrate and
> may be that's why less likely to make mistake. Is my observation
> correct or simply my imagination?
This is the distinction between "statements" and "expressions" too.
Statements are supposed to follow one another linearly, but
expressions are meant to have values and be nested. Since Lisp only
has expressions, and no statements, everything can be nested. It is
appropriate, in an expression-oriented language like Lisp, to think
about computations from the most deeply nested expressions on up.
However, if you are focusing on the parentheses you are making a
mistake. The key element of Lisp code is the source code "form" which
is either an atom like X, 1, or 3.14, or a list like (+ 1 1). Forms
are expressions that have valid semantics in the Lisp language. You
should be concentrating on creating proper forms, and letting your
editor do the work of managing parentheses.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
"Anthony Pang" <···········@gmail.com> writes:
> And with
> so many parenthesis, it really forces user to concentrate and may be
> that's why
> less likely to make mistake. Is my observation correct or simply my
> imagination?
It's an imagination forced upon you by a severely crippled edtior.
Please either fix the settings in your editor or find one that can be
fixed. All the different Emacsen as well as vim can edit lisp quite
well.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Anthony Pang escreveu:
> I am a newbie to lisp so I did not aware of the rational type in the
> language.
> As more information is provided, the compiler/interpretor can do
> exactly what
> the user wants. But when insufficient information is provided, the
> implementation
> of compiler/interpretor provide a default setting for the missing
> information.
Let's start with rational then:
If you did this in your REPL (a way to convince people in our lab about
some 'different' capabilities of Lisp):
CL-USER> (+ (read) (read))
1/3
4/6
1
CL-USER>
Where the 1/3 and the 4/6 are the fractions typed in by the user, look
at the result. In fact for non believers, you can even go a little further:
CL-USER> (defun sum (x y)
(format t "Adding ~d and ~d.~%" x y)
(+ x y))
SUM
CL-USER> (sum (read) (read))
1/3
4/6
Adding 1/3 and 2/3.
1
Notice the work Lisp does for you. Probably elementary school teachers
wuold forbid Lisp interpreters in the school computers to avoid kids
cheating in their fraction assignments!
> In the case of my simple example, when lisp see 3.14, it has a choice
> to store
> it as a double-precision or single-precision float and it decided to
> store it
> as single-precision. In both cases, they are not precise. My point is
> that the
> default implementation may want to take the underlying hardware into
> consideration.
Well your example for 3.14 probably is thinking of pi, which cannot be
expressed in a rational form, right?
> After all, I am pretty new to lisp, I think lisp language has so much
> to offer and
> I want to see whether certain behaviour of the language has some hidden
> meaning
> or it just stay the way it was.
The meanings are all standarized, no hidden meanings, except perhaps for
some elusive bug ;-)
--
Cesar Rabak
Cesar Rabak <······@acm.org> writes:
>> In the case of my simple example, when lisp see 3.14, it has a choice
>> to store
>> it as a double-precision or single-precision float and it decided to
>> store it
>> as single-precision. In both cases, they are not precise. My point is
>> that the
>> default implementation may want to take the underlying hardware into
>> consideration.
>
> Well your example for 3.14 probably is thinking of pi, which cannot be
> expressed in a rational form, right?
Either way, you're in trouble when you use floating point. FP numbers
are basically a very restricted subset of rationals that have fancy
rounding rules so that approximate calculations can be predictably done
that don't lose precision in disastrous ways.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain escreveu:
> Cesar Rabak <······@acm.org> writes:
>
>
>>>In the case of my simple example, when lisp see 3.14, it has a choice
>>>to store
>>>it as a double-precision or single-precision float and it decided to
>>>store it
>>>as single-precision. In both cases, they are not precise. My point is
>>>that the
>>>default implementation may want to take the underlying hardware into
>>>consideration.
>>
>>Well your example for 3.14 probably is thinking of pi, which cannot be
>>expressed in a rational form, right?
>
>
> Either way, you're in trouble when you use floating point. FP numbers
> are basically a very restricted subset of rationals that have fancy
> rounding rules so that approximate calculations can be predictably done
> that don't lose precision in disastrous ways.
>
:-) You're trying to starve a lot of people that make their livig from
these shortcomings in other programming languages?
I was not concerned about the "subset of rationals". The problem is the
irrational ones pi, e, nth-roots and all transcedental functions. If try
to keep too much their purity, you may end into an almost symbolic
calculation (as Maxima is now), isn't it?
Cesar Rabak <······@acm.org> writes:
> I was not concerned about the "subset of rationals". The problem is the
> irrational ones pi, e, nth-roots and all transcedental functions. If try
> to keep too much their purity, you may end into an almost symbolic
> calculation (as Maxima is now), isn't it?
Yes. Rational math actually just one step on the way to what you're
describing.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Hi Anthony Pang,
> In the case of my simple example, when lisp see 3.14, it has a choice to
> store it as a double-precision or single-precision float and it decided
> to store it as single-precision.
[Assuming implementation support for IEEE-style single and double floats]
(type-of 3.14) => SINGLE-FLOAT
(setf *read-default-float-format* 'double-float)
(type-of 3.14) => DOUBLE-FLOAT
Set this in an initialisation file and you'll always input floats as
double floats by default. You could also have typed 3.14d0 to override the
default float format.
Regards,
Adam
Rahul Jain <·····@nyct.net> writes:
> Floating point numbers will ALWAYS be imprecise.
The floating point numbers themselves are precise, but the operations
on them are allowed to return approximate results if necessary.
Often, however, they can return the exact correct answer.
Joe Marshall <···@ccs.neu.edu> writes:
> Rahul Jain <·····@nyct.net> writes:
>
>> Floating point numbers will ALWAYS be imprecise.
>
> The floating point numbers themselves are precise, but the operations
> on them are allowed to return approximate results if necessary.
> Often, however, they can return the exact correct answer.
Yes. I am far too imprecise with the way I say that. ;)
"Computation using floating point numbers will be imprecise, in
general..." but that doesn't quite have the right effect, does it? Maybe
I should just say that floating point numbers are only beneficial when
you don't care about getting the exact answer, just an approximation?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Kenny Tilton wrote:
> The thing is, when a newby hits some surprising feature of CL, they do not
> realize it is an FAQ, they think CL has gone mad. CL being so different
> from the Fortran tree of languages.
>
Ha, Ha, Ha! I love it:
Common Lisp. Not mad. Just different.
or
Common Lisp--it's not so bad being mad...