dgary@ecsvax.UUCP (06/18/84)
<> >From: anand@utastro.UUCP Mon Jun 11 08:05:01 1984 > >My recommendation is DON'T GET UNIX!!!!!!!!!!!!!!! > >A lot of scientists still use FORTRAN, so a shaky, unreliable >f77 compiler is a severe drawback, and I believe a scientific, heavily >arithmetically oriented department cannot afford to base its computation >on UNIX's FORTRAN. >From: elt@astrovax.UUCP Tue Jun 12 10:47:25 1984 >The best solution, in my opinion, is to switch to C thus getting a good >compiler and a superior language; to the extent that the new f77 compiler >motivates people to do this, it may be a good thing. Incidentally, the >advantage to a physical scientist of a computer language superior to >FORTRAN is analogus to the advantages of a superior mathematical notation. > >Of course, switching to C cannot be the whole solution given the existence >of enormous amounts of useful FORTRAN code, portability requirements, and >the fact that some people simply won't switch. There must be a substantial >amount of money to be made by producing a first class FORTRAN compiler that >runs under 4.2. Having spent a good portion of the last decade giving hell to physicists for using FORTRAN, I'm a little sheepish about coming to its defense. It is certainly true that FORTRAN is an awful language from many standpoints. It is also true that a good part of the reluctance to switch from FORTRAN to something better is plain old inertia. But I have reservations about C being better than FORTRAN for scientific programming. In fact, I don't know of anything better than FORTRAN for scientific programming (he said, crawling into his well-protected bunker). FORTRAN is unique among modern programming languages of any wide use and acceptance in that it is specifically designed for numeric programming. It has an exponentiation operator (**). It has a large, STANDARD set of function names for widely-used functions. (I consider this its single greatest strength, by the way.) It has an immense body of non-standard but widely available, pre-coded scientific functions (IMSL, for instance). The only competition I see on the horizon is (heaven help us) Ada. If you are aware of a language (other than Ada or PL/I) that does numerical programming as well as FORTRAN, please, PLEASE tell me. In the meantime, a good preprocessor for FORTRAN 77 may be the best thing for scientific programmers to use. Defensively, D Gary Grady Duke University Computation Center, Durham, NC 27706 (919) 684-4146 USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
allan@noao.UUCP (06/19/84)
I would like to agree that fortran is a good language for number crunching
type programs. Of course, for other types of programs it leaves a lot to be
desired, but most/many/some/my scientific programs are just number crunchers.
If you have a good optimizing compiler then they are hard to beat.
One example with which I am particularly familiar:
Dr. Richard James at Manchester has a large N body program to simulate
spiral galaxies. It is very important to make this program run as quickly
as possible since each run of the program takes several hours on a CDC7600
(this story is from the pre-Cray days). To try to speed up critical sections
of the code he tried writing some routines in assembly language. He often
found that he could not improve on the code that the compiler generated.
I think that, inetia apart, there are some good reasons for keeping fortran
around. These days the fastest computers have what might be loosely termed
'array processor' architectures, e.g. hardware vector operations (Cray & CDC205)
and array processor add-ons for vaxes. To make the best use of the speed of
these computers it is necessary to use a language that can easily take advantage
of the hardware features. An advantage of fortran for this task is that it is
a fairly simple language. I believe that it is the only language that has
had optimization features included for the array processor architectures
(of course, this is because it is the language that scientists use .... ).
Languages such as C and Algol68 are very nice to use for non numerical
applications where the (still) primitive character features of fortran are
a real pain, but when you must have the greatest speed possible in a numerical
application, you simply cannot beat fortran.
Peter Allan
Kitt Peak National Observatory
Tucson, Az
UUCP: {akgua,allegra,arizona,decvax,hao,ihnp4,lbl-csam,seismo}!noao!allan
ARPA: noao!allan@lbl-csam.arpa