Skip to content

APL at the Leading Edge: Nov 18th at the Royal Over-Seas League

Vector 5:3, page 56

APL community performance

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 56

Allan Prys Williams contrasted the way APL works with the way a rule-based system is built, and ended by showing how you could combine the approaches to provide existing software with an intelligent front-end. His notes follow this introduction.

Brian Lochran showed how United Glass had moved a substantial APL planning system from a mainframe (ADRS II) environment to a network of IBM 6150 machines using Dyalog APL and SQL. His notes are on page 75.

John Adams reviewed his experiences at the recent APL/AI conference in New York. His notes appear in VECTOR 5.2.

Finally, Tom Lake of Intercept Systems gave us an overview of parallel systems. This was one of those useful talks which came from a non-APL perspective. Tom defined 'parallel' as "several computers under the control of a single program". He described the evolving 'culture of the parallel' in applications such as:

  • the simulation of physical systems. Fluid flow, weather forecasting, aerodynamics and so on. Also analysis of stress in engines and structures.
  • animated graphics. This could be anything from Walt Disney to studies of molecular folding in drug design.
  • image processing, particularly of radar and sonar images.

There are two approaches to building a parallel system:

  • by repetition. The pipeline approach: instructions follow each other in short order through custom-designed chips. 20 Mflops are achievable if you keep them fed.
  • by replication, e.g. DAP which has 4096 little simple processors all doing the same thing. Programmed in a sort of FORTRAN using vector and array types in a vaguely APL-ish sort of way.

Tom closed by noting that parallel people are willing to put a lot of work into the program to make life as easy as possible for the compiler. APL is something of a paradox, being a language where someone put a lot of work into the interpreter to make life as easy as possible for the programmer, and yet it seems eminently suitable for parallel processing. As was said of Chi Chi and An An "why don't they get on with it!".