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