tang@venus.ycc.yale.edu (12/01/90)
tmb@bambleweenie57.ai.mit.edu writes: >Not surprisingly--anything else is very cumbersome to express in >FORTRAN--and if FORTRAN is all a scientific programmer is familiar >with, he'll easily dismiss good algorithms as "too complicated" that >are naturally and simply expressed using highly linked data >structures, closures, lists, etc. To add to the insult, computer >manufacturers like Cray have built whole machines based on the idea >that all people want to do is loop sequentially through arrays. > >Hopefully, once scientific programmers switch to more expressive >programming languages (like FORTRAN 9x, C, C++, Modula-3, Scheme, ML, >Haskell), scientific programming will be liberated from such limited >paradigms. Arrays and loops are very important, but the are not a >panacea. While I agree that efficient code and well-written code are two different things, I find it hard to agree that the bulk of scientific and numerical computation require substantially more than looping. Unless one dismisses the importance of Taylor series or Fourier series in science, it is obvious that series and linear algebra are tightly related to loops, and hence, the importance of loops in scientific computation. Tang
tmb@bambleweenie57.ai.mit.edu (Thomas M. Breuel) (12/03/90)
In article <655.27566753@venus.ycc.yale.edu> tang@venus.ycc.yale.edu writes: tmb@bambleweenie57.ai.mit.edu writes: >[complaints about the fact that just about the only data structure >that can be expressed naturally in FORTRAN is the array] >Arrays and loops are very important, but the are not a panacea. Unless one dismisses the importance of Taylor series or Fourier series in science, it is obvious that series and linear algebra are tightly related to loops, and hence, the importance of loops in scientific computation. This is precisely the attitude I'm criticising. As I stated in my posting, arrays are indeed good data structures to represent vectors and series, and loops are often good control structures to operate on them. But there are also many cases when they aren't. Some useful data structures and control structures are: * series as infinite streams * 1D or 2D data as functions (from R or R^2 into R) * depth first, breadth first, A* search over graphs * number-like objects such as quaternions (some of these cannot be represented as monotype vectors) In fact, for Taylor and Fourier series, it can be much more appropriate and, sometimes, even more efficient, to represent them as streams and not arrays. (Pre-90) FORTRAN gives me virtually no support to build abstractions and data structures like these. C has dynamic allocation, pointers, and structures, which helps significantly. Modula has limited lexical scoping, which helps build control abstractions. Scheme and functional programming languages are expressive enough, but compiler technology is not quite advanced enough yet for serious number crunching, although statically typed languages with eager evaluation will probably soon be close to FORTRAN or C performance. As I said before, as far as I'm concerned, the FORTRAN and C mindset is hopelessly outdated. Currently, people make do with the best compromise between availability, expressiveness, and efficiency. In my case, that happens to be C (FORTRAN is just too restrictive), for other people it happens to be FORTRAN. However, I find the attitude "FORTRAN is all I need--it can do anything I want in it" disappointing. You won't know what you are missing until you look. And, until a significant number of numerical programmers looks over the fence of FORTRAN-90 and puts pressure on their vendors to develop and supply them with hardware and software that executes more programmer-friendly languages more efficiently, not much will happen.