Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ttrdc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!mgnetp!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang,net.lang.lisp
Subject: Re: Re: Re: Using LISP for scientific programming? (gasp!)
Message-ID: <526@ttrdc.UUCP>
Date: Sun, 27-Oct-85 18:02:57 EST
Article-I.D.: ttrdc.526
Posted: Sun Oct 27 18:02:57 1985
Date-Received: Mon, 28-Oct-85 04:15:06 EST
References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> <2034@hcrvax.UUCP> <454@harvard.ARPA>
Distribution: net
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 55
Xref: watmath net.lang:1887 net.lang.lisp:597

In article <454@harvard.ARPA>, munyer@harvard.ARPA (Robert Munyer) writes:
>This is in response to article <2034@hcrvax.UUCP>, from Peter Ashwood-Smith:
>a similarly straightforward manner.
>
>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")

If your variables are getting that big, and you are programming on a conven-
tional machine in a conventional language like C or Fortran, you should use
the double precision data type.  You will still get accuracy equivalent to that
of using Lisp's oversize integers up to a magnitude of 2^58 or so (depends on
how many bits the exponent takes up on the particular machine).   That's on
the order of 10^17.  I mean how much accuracy do you want???  Also, many
(conventional, caveat here) machines have instructions for automatically hand-
ling the double precision numbers, unlike the juggling which would have to take
place in Lisp simulating this with integers.  And if that doesn't quite meet 
your absolute accuracy requirements, some conventional machines (e.g. VAX)
have a "quadruple precision" data type that is handled atomically by machine
instructions.  I fail to see, in the light of this, where "jobs for which
Lisp is a better language than FORTRAN [or C, or whatever] vastly outnumber
those 'numerical' jobs which have traditionally been done in FORTRAN [etc.]"
--at least on conventional machines.  Of course if you have a socalled Lisp
machine which is designed to atomically handle this kind of stuff, that
throws the whole comparison out the window, you're comparing apples with
oranges.  When you get right down to it, whether you be programming in Lisp,
C, Fortran, Occam, Pascal, or Swahili for that matter :-) what MATTERS is
the resultant machine-level activity.  I doubt that an assembly-language
programmer would choose a Lisp-like approach any more than a Fortran or C-
like approach, on a conventional machine.  Anything higher level than that
is a convenience in interface for the programmer and nothing more sacred
than that.  If you have a marvelous Fortran compiler/optimizer that can
make up for a lot of sins in the language style, same goes for other languages.
I begin to think I am expounding on the obvious so I had better stop here.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!ihnp4!ttrdc!levy