Newsgroups: comp.lang.apl
Path: watmath!watserv1!torn!utcsri!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!hermes.chpc.utexas.edu!jonathan
From: jonathan@chpc.utexas.edu (Jonathan Thornburg)
Subject: Re: SIGNUM of teaching numerical methods
Message-ID: <1992Jul17.171448.13672@chpc.utexas.edu>
Summary: (long) example of how APL doesn't (yet) help with scientific computing
Keywords: APL numerical analysis scientific computing SVD PDE sparse matrix
Sender: jonathan@einstein.ph.utexas.edu (Jonathan Thornburg)
Organization: U of Texas at Austin / Physics Dept / Center for Relativity
References: <1060@kepler1.rentec.com> <1992Jul15.093105.22737@math.waterloo.edu> <1072@kepler1.rentec.com>
Date: Fri, 17 Jul 92 17:14:48 GMT
Lines: 119

In article <1072@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt)
writes:
| [very nice description of why APL doesn't really have
|  that much to offer to much of scientific computing]

Alas, I have to agree with Andrew.  Due to a combination of
(in)efficiency, very awkward scalar control structures, an uncommon
character set, and expensive implementations (yes, I know about J; it
may change this when it's finished, documented, and widely available),
at present few people doing scientific computing find APL worth the
trouble to learn and use.  This may change, but alas I think the odds
are against it, and getting worse with time.

An example:  I have spent the past 6.5 years working on a code to
simulate the time evolution of black hole spacetimes.  This code
sets up and solves a very complicated set of coupled elliptic-hyperbolic
nonlinear PDEs which determine the "gravitational field".  The work
done is a mixture of repeatedly sweeping a 2-D grid doing simple
operations on the field variables (a bunch of small matrices) stored
at each grid point, and sparse matrix permutation, LU decomposition,
and back substitution.

The code is written in C (30K lines), but calls some Fortran library
routines (Linpack, Eispack, SPARSPAK, ILUCG, and Forsythe/Malcolm/Moler,
5K or so lines total).

Looking back on the project, I can see only one place where APL would
have been really useful:
- About 1/3 of the (C) code is what I now realize is a crude and
  special-purpose symbolic algebra system.  In hindsight, this should
  have been written in a *real* symbolic algebra system, probably
  Macsyma, Maple, or Mathematica.  (It would then have been only 1K
  or so lines, and taken < 1 year to develop, rather than 15K and
  3 years.)  (No big APL win here.)
- About 1/3 of the (C) code is devoted to the physics itself.  It's
  effectively written in a specialized "tensor PDE" language provided
  by by the "crude and special-purpose symbolic algebra system".  This
  too should really have been written in a real symbolic algebra system.
  (It would have only shrunk by O(30%) in size and development time,
  though, due to the complexity of the physics involved.)  (No big APL
  win here, either.)
- The remainder of the (C) code consists of misceleanous support routines
  and interfaces between my data structures and those of the various
  (Fortran) sparse matrix libraries.  APL would have helped a bit here,
  but only if it offered clean interfaces to these same (or equivalent)
  libraries.
- The Fortran library routines are the most APLish; they mostly do
  various matrix operations.  But APL doesn't support most of these
  -- few APLs offer quad-slope for eigensystem computation, or the
  ability to cleanly specify computing eigensystems of 4000 3*3 matrices
  all at once.  And most of the code's CPU time and memory is actually
  spent inside the SPARSPAK sparse LU decomposition routines.  These
  are very ugly in Fortran, but would be only slightly less ugly in 
  most APLs I'm familiar with.

And where *would* APL have been really helpful?  For the interactive
graphics and data manipulation.  I kludged together a C program to
do this, but it doesn't work very well.  I'm thinking of trying APL
(perhaps J?) for this in my next code, because here efficiency isn't
a major problem, there isn't any sparse matrix manipulation, and
having an interactive interpreter is essential.

But using, or trying to use, APL in this environment raises two other
points:
- The world doesn't speak the APL character set.  Soft fonts are
  great, and I love the visual beauty of the real APL character set,
  but none of machines I use has an APL keyboard.  Moreover, I need
  to collaborate with colleauges who have different and even less
  APL-aware hardware.  (Try sending an APL function in an E-mail
  message and see what happens...)  "ASCII-APL" schemes are really
  essential for APL to prosper.  Unfortunately, most of the existing
  ones are pretty unpleasant to use and to look at.
- I DON'T WANT TO REINVENT THE WHEEL!  The state of the art in dense-
  matrix numerical linear algebra is LAPACK.  Therefore, I want to
  *use* it, not *reimplement* it.  When I'm ready to run my code on
  a Cray, the CPU-intensive parts have to vectorize, which probably
  means Fortran.  I want to use already-written (Fortran or C) graphics
  libraries like NCAR, PHIGS, etc.  All of this means that a good
  foreign-function interface is essential.  As others in this thread
  have pointed out, that means avoiding making a duplicate copy of the
  data, not requiring source code to the Fortran routines, and being
  able to handle both Fortran and C (including C that uses malloc(3) ).

I look forward with interest to J stabilizing; at that point I'll take
a good look and see whether or not it can become my "interactive data
editor, manipulator, and graphics utility program".  But there's stiff
competition here, from packages like Gauss, Matlab, IDL, NCSA Datascope,
and others.  APL is much more powerful than them, but they have lots
of fancy functions built-in which APL has to get via foreign-function
calling to Fortran libraries.

One final point:  Money.  Good commercial APLs for workstations cost
O($2K) these days, perhaps as low as O($1K) with academic discounts.
That's still large enough that it's hard to persuade my boss to spend
the money.  (For various psychological reasons, he is much more willing
to spend $15K on new hardware than $1.5K on new software.  I might
feel differently, but he's the boss, not me.)  Symbolic algbebra systems,
interactive data manipulation packages, and other large software systems
are also expensive, but they're already established and widely available.
For example, Maple is available to me on several different systems only
an rlogin away, so I can start using it "for free", and get a demo
application on the air quickly.  If I then find I need a local copy of
Maple, I have *results* to help convince my boss to spend the money.
The only comparable thing for APL is J, but it's a separate dialect,
and so has both a much longer learning curve for me (trained in "classic"
APL but not in J) and a much higher barrier to switching to another APL
if that later proves desirable.

So, where do we stand for scientific computing in APL.  *Good* foreign
function interfaces are essential, as are *pleasant-to-use* ASCII-APL
schemes.  J has the right price, and seems to be available on lots of
different machines, but is still not stable.  Meanwhile the number of
people actively using C++ is doubling about every 6-9 months.  Alas,
APL isn't catching up, it's being left behind.

- Jonathan Thornburg
  <jonathan@einstein.ph.utexas.edu> or <jonathan@hermes.chpc.utexas.edu>
  University of Texas at Austin / Physics Dept / Center for Relativity
  and (for a few more months) U of British Columbia / {Astronomy,Physics}
