Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: net.lang,net.lang.lisp
Subject: Re: Re: Using LISP for scientific programming? (gasp!)
Message-ID: <3493@utah-cs.UUCP>
Date: Tue, 22-Oct-85 15:12:36 EDT
Article-I.D.: utah-cs.3493
Posted: Tue Oct 22 15:12:36 1985
Date-Received: Thu, 24-Oct-85 06:04:38 EDT
References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> <1071@sdcsvax.UUCP> <3785@garfield.UUCP> <86@mit-eddie.UUCP> <2018@hcrvax.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley shebs)
Distribution: net
Organization: Univ of Utah CS Dept
Lines: 17
Xref: linus net.lang:1654 net.lang.lisp:528

In article <2018@hcrvax.UUCP> petera@hcrvax.UUCP (Smith) writes:
>
>	One thing that is ineffecient when using LISP for numeric computations
>is that on many machines a new cell is created for a new value of any numeric
>type.
>		Peter Ashwood-Smith

This is *entirely* a property of the Lisp implementation and therefore
depends only on the intelligence of the implementors.  For instance, PSL
does *not* do any allocation for numbers (except bignums, for which
there's no choice), but Franz allocates storage for any number outside
the range +-1023.  This is partly responsible for the fact that PSL
programs are up to an order of magnitude faster than the same programs
in Franz.  If I wanted to start arguments, I could comment on the
relative merits of BBOP vs tagging....

							stan shebs