Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!kurtk From: kurtk@tektronix.UUCP (Kurt Krueger) Newsgroups: net.physics Subject: Re: Languages for number crunching Message-ID: <5910@tektronix.UUCP> Date: Fri, 8-Nov-85 13:58:54 EST Article-I.D.: tektroni.5910 Posted: Fri Nov 8 13:58:54 1985 Date-Received: Sun, 10-Nov-85 09:27:08 EST References: <722@sri-arpa.ARPA> Reply-To: kurtk@tektronix.UUCP (Kurt Krueger) Organization: Tektronix, Beaverton OR Lines: 24 Summary: I still see Fortran as the number crunching language. The approach for vector machines has been two fold, to work on both language extensions and creating compilers that recognize language constructs that can be vectorized. The best success appears to be in the language extension camp, as fortran's constructs don't lend themselves to easy vectorizations (don't forget, fortran was 'invented' when computers had a single accumlator and vacuum tubes). I must say, though, that the 'smart' compilers are getting there. Two big forces in this currently are CDC (the 205 line) and Cray. Another force is represented by the array processor folks. Floating Point systems has a Fortran compiler for their processor. An approach that I've never seen suggested would be to use the APL language. It has vector and matrix operations built into the language. It would require NO language extensions to use vector hardware and since each command is so powerful, an interpreter (which most APL implementations are) running on a vector machine should really perform. I won't get into a discussion of the relative merits/demerits of APL. It is not a very popular language but it is a natural for vector processors.