Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!munyer
From: munyer@harvard.ARPA (Robert Munyer)
Newsgroups: net.lang,net.lang.lisp
Subject: Re: Re: Re: Using LISP for scientific programming? (gasp!)
Message-ID: <454@harvard.ARPA>
Date: Sat, 26-Oct-85 07:51:19 EST
Article-I.D.: harvard.454
Posted: Sat Oct 26 07:51:19 1985
Date-Received: Sun, 27-Oct-85 07:30:01 EST
References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> <2034@hcrvax.UUCP>
Reply-To: munyer@harvard.UUCP (Robert munyer)
Distribution: net
Organization: Aiken Computation Laboratory, Harvard
Lines: 77
Xref: watmath net.lang:1884 net.lang.lisp:596

This is in response to article <2034@hcrvax.UUCP>, from Peter Ashwood-Smith:

>>		You should be aware that the SYMBOLICS 3600 fits 32bit
>>		floats directly in the pointer field of objects, so for
>>		single precision there is no garbage.  Such a
>>		capability does seem to be essential for fast numerical
>>		analysis in lisp.

>	I don't understand? Using the car or cdr field of a CONS cell
>	as a floating point number does not stop you from getting
>	garbage because you still cannot operate on that location...
>
>	(eq 4 (+ 2 2)) is nil because they are not the same floatnum atom...
>
>	If we use the standard (setq) function such as:
>	(setq 'n (+ n 1)) then we have created a new value for 'n and the
>	old one is still hanging around....

You seem to be missing the point.  The idea is that it is possible (and
necessary, if you want to be able to crunch numbers) to implement Lisp
in such a way that adding two numbers does NOT require allocating
storage to represent the new number.  A simplified explanation follows:

The idea is based on the fact that nobody really NEEDS to be able to
use an entire 4 gigabyte address space for pointers to list cells.  So
you can set aside some fraction of this address space, say 128
megabytes, and arrange that no list cells will ever be stored at these
addresses.  You now have about 128 million "unused" addresses which you
can use to represent about 128 million integers.  You simply treat a
pointer which contains one of these addresses as if it were a pointer
to a "numerical atom", although in reality it does not actually "point"
to anything because there is nothing stored at that address.

Now, when you need to represent the number 4, instead of allocating a
block of memory, copying 4 into it, and returning a pointer to that
block, you can instead simply return a pointer to the 4th "unused"
address.  To increment the number represented by one of these pointers,
you simply return a pointer to the following address.  This has the
desirable quality that the Lisp form

	(setq n (add1 n))

can be compiled to the machine language instruction

	increment register 2

, presuming that the variable n is used frequently and that the
compiler is intelligent enough to use registers for frequently used
variables.  If you put your unused addresses at the very bottom and top
of the address space, then you can compile addition, subtraction &c. in
a similarly straightforward manner.

So far we have the Lisp compiler doing basically the same thing the
FORTRAN compiler would do, for "small" integers.  The difference comes
when your numbers get very large.  If you are using FORTRAN and your
variable gets larger than 2,147,483,647, you are out of luck.  Your
program will crash or, worse yet, give incorrect results.  If you are
using one of the newer implementations of Lisp and your variable gets
larger than, say, 67,108,863, it will no longer be represented by one
of these "bogus" pointers.  Instead, a block of memory of sufficient
size to store the bits of the number will be allocated, and the
register will contain a real pointer to this block.

As a result, the Lisp user sees no limitation on the size of numbers
the system can handle, except for a decrease in speed and an increase
in garbage collection when the numbers become "large".

In my opinion, jobs for which Lisp is a better language than FORTRAN
vastly outnumber those for which FORTRAN is better, even if you only
consider those "numerical" jobs which have traditionally been done in
FORTRAN.

		((name "Robert Munyer")
		 (address (uucp  "...allegra!harvard!munyer")
			  (arpa  "munyer@harvard")
			  (Snail "18 Morton St. #2, Somerville MA 02145-4206")
			  (phone "(617)628-8083")))