From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.lang.apl
Subject: Re: Promoting APL2
Date: 15 Aug 92 20:48:21 GMT
Organization: Renaissance Technologies Corp., Setauket, NY.

In article <1992Aug13.171145.24691@csi.jpl.nasa.gov> sam@csi.jpl.nasa.gov (Sam Sirlin) writes:
>
>In article <168417F7D.JOHNSON2@vm.cc.purdue.edu>, JOHNSON@vm.cc.purdue.edu writes:
>I don't know what would end up being most popular, but for me there
>are a few neccessities:
>
>1. linear algebra - as much of eispack/linpack/lapack as you can get.
>Perhaps you could link them in via some sort of quad na? I've
>translated the qr and qz eigensystem paths into APL if you want them.
>I have them in readable ASCII form.

NO! NO! A thousand times NO!. These guys have a 3090, and they should use
ESSL, which is provided by IBM. Although ESSL has some trivial flaws, it
is probably the only commercial package which is as good or better than
LINPACK/EISPACK/LAPACK. ESSL has the world's _best_ FFT's bar none. (what
else would you expect from Winograd et. al.?) Last time I used it, IBM
had gone to the trouble to write the required interface for all of ESSL
routines to quad-NA. Use the IBM provided ESSL.

Also: there was talk that OSL would be done in the same way - if so use
that for all of your constraint-bound optimizations.

>2. ode solvers - the more the better. Some sort of rk45 for example.
>This also needs to include random colored noise generators (for
>example the OU of ACSL). A stiff method would be nice.

A painful issue with APL, since you have to call the function defining
the DE from the solver. I've been told that APL2 can _now_ be called from
FORTRAN, but I've never seen it. If you can't, it's too bad. If you can,
your best bet is to use FORTRAN versions.

>4. random number generators - for the various processes. At least
>Gaussian and Poisson.

ESSL provides a good uniform generator.

>5. integration methods - I don't really need to much here, trapezoidal
>rules and Simpson seem to work. 

ESSL provides several excellent methods. Linking in quadpack would
be even better, but we run into the "can FORTRAN call APL" problem
again.

>6. special functions - Bessel, erf, etc.

Although you can profitably construct these using ESSL, you might
be better off linking in PD FORTRAN code.

>7. controls analysis - frequency response calulation etc. Well that's
>what I want anyway... 

A good chunk of the foundationns you need for this is provided by
ESSL's rich and "world's best" FT/Correlations/etc. functions.

>8. data translation - functions for reading/writing data from/for
>other languages (fortran). This also includes text manipulation - one
>of APL's strong points since (at least STSC/J) can read exactly what's
>in a file.

But they live on a 3090, which might be running MVS. In which case
the file system is a disaster beyond comprehension.

A few more things about ESSL - ESSL is finely tuned to take advantage
of the resources the 3090 offers, even across different models of the
3090. It can take advantage of vector heads, as well as run on multiple
heads, for some functions. APL2 on the other hand only makes use of
vectorization, at least last time I looked.

Later,
Andrew Mullhaupt
Newsgroups: comp.lang.apl