Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!spool.mu.edu!uunet!elroy.jpl.nasa.gov!jato!csi!sam
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: Weaning  myself from Matlab: is APL a viable alternative for scientific programming and signal processing?
Message-ID: <1993Jan19.012451.9402@csi.jpl.nasa.gov>
Originator: sam@kalessin
Sender: usenet@csi.jpl.nasa.gov (Network Noise Transfer Service)
Nntp-Posting-Host: kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
References:  <IBE1109.93Jan17152519@etbsun1.draper.com>
Date: Tue, 19 Jan 1993 01:24:51 GMT
Lines: 122


In article <IBE1109.93Jan17152519@etbsun1.draper.com>, ibe1109@draper.com (Ira Ekhaus) writes:
|> My only knowledge of APL is that MATLAB is "similar", and I'm curious
|> about APL.

I do quite a bit of work in both, though for APL I mostly use J. I
suppose you should also say ProMatlab, as opposed to the (original)
Fortran Matlab or XMath (MatrixX) which we've also used here. My
section at JPL (at least those who do technical work) are heavy Matlab
users, but I'm the only one who uses APL much.

|> For my own case, the beginning of  a typical  project  has the relative
|> weight of C and matlab code:
|> 
|> data <---C  --------><-------------matlab  ----------> postscript files for  reports

I add postscript graphs -> TeX documents. But I write memos and papers
primarily. We mostly use Fortran mexican files (.mex, dynamically
linked to the interpreter).  

|> but  as the processing stages mature, I change them to C.
|> 
|> data <---C  ----------------------------><-matlab ---> postscript files for  reports
|> 
|> Although  Matlab is  a very good product, I'm constantly running into
|> the following limitations:
|> 	1)arrays are limited to two dimensions

A real problem APL never had.

|> 	2) no data structures. 

APL has two (too many) solutions to this now, and the community has
been arguing unproductively (no agreement, no standard) about this for
10 years or so. If you stay in one world (vendor) you are probably ok
here though. 

|> 	3) Sometimes , it takes a great deal of effort to avoid 
|> 	the dreaded interpretive mode which is very slow.

APL has the same problem. Someday maybe compilers will help...

|> Even with all these problems, the language itself is so convenient
|> that it's hard not to use, its the closest thing to a "numeric oscilloscope"
|> that I've seen for signal processing development.

That's why I started using APL long ago, and exactly why Matlab caught
on so fast, especially in the controls community.

Some of the Matlab limitations are being addressed: Several "free"
versions are being developed at various places. Some are available
now. One I know of has structures and some sort of byte-code
compilation for speed. I think (as Andrew Mullhaupt has said already)
that APL has had lots of fundamental thought as to theoretical
underpinnings of things (the "operator" [or functional programming for
those outside the community] concept for example) that hasn't yet been
done for most other languages.

|> Now, I'd like to correspond with people about their experiences with various
|> versions of APL. Not only the language, but the total environment
|> of which APL 
|> would be a part:
|> 	Comparisons with Matlab (power of language, memory usage, speed),

I'd say APL (J) is probably slower, and is missing lots of important
functionality (linear algebra). But it's a much better language, and
much easier to write programs in. One thing you haven't mentioned is
character/string manipulation which I regard as non-existant in
Matlab. So if I'm working on a number crunching application (say
calculation of closed loop transfer functions for large mechanical
systems), I use Matlab/Fortran for speed and compatibility (so other
people can use the results). But if I'm doing something standalone,
that I'd like to do fast, and isn't completely defined at the moment
(say determination of centroiding errors on a ccd detector after going
through a fiber optic bundle), I use J. I also use J to make programs
that write parts of Fortran code, in support of an all Fortran optics
analysis program (system identification). 

My guess is the Matlab crowd (vendor or free) is more concerned with
speed and will stay ahead there using dynamic linking to other
languages. I suspect they will stay behind for a long time on language
power and expressiveness though. I suppose these two areas are
mutually exclusive to a large extent. Compilers hold out hope (I'm
playing with one and have the idea of using a .m to .apl translator)
but are either not available much or not very usable yet.

|> 	ways to link up with C and Fortran ,

It's possible in J (since C source is available), but I haven't
tackled it yet. Other dialects of APL have it too, each using their
own system. Can this be made simple? .mex files actually work pretty
well considering that source isn't available.

|> 	ways to plot data (vectors or matrices) on the screen , 

The first thing I have to port/build on a new APL. I have some simple
line drawing routines that have served me well for quite a while.
Matlab 4 has lots of really nice graphics.

|> 	ways to output graphical images to a file

I use tektronix 4010 drawing commands -> .tek file -> postscript files
using various unix filters -> etc.

|> 	price and availability of various implementations.

I posted the FAQ, but it doesn't have prices. For pc's there are lots
of options. For workstations, I expect $$$ for comercial versions
(this at least was true), or free for J (can you guess what I use?). 

|> 	Any versions of APL running under (exploiting aspects of) an
|>      X11 environment? 

The comercial versions I think (from STSC/Manugistics' literature) do
a good job with this. I ported my ancient tekronix plotting routine to
work under an xterm. If I get motivated I might do more... but that's
unlikely for quite a while. 

-- 
Sam Sirlin
Jet Propulsion Laboratory         sam@kalessin.jpl.nasa.gov

