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.