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")))