Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.lang.apl
Subject: Re: Syntax for extended matrix operations
Summary: Why? Because it's not there...
Keywords: APL primitives, beyond quad-divide
Message-ID: <558@s5.Morgan.COM>
Date: 1 Dec 89 04:45:19 GMT
References: <539@s5.Morgan.COM> <6458@tank.uchicago.edu>
Organization: Morgan Stanley & Co. NY, NY
Lines: 90

In article <6458@tank.uchicago.edu>, jeff@zem.uchicago.edu (Jeff Adler) writes:
> In article <539@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> >I would like to solicit suggestions for primitives to be added to
> >the APL lexicon which would update the representation of linear
> >algebraic concepts...
> >
> >in the APL syntax.
> 
> Rather than trying to get APL to do everything, wouldn't it be better
> to have APL
> 	1. do a small number of things really well,
> 	2. have hooks into other programs with other capabilities?
> 
> Isn't this the point of quadNA?  If you need some fancy mathematical
> functions, what's wrong with calling standard routines from a library?

Well for one thing, most of those wonderful FORTRAN oriented libraries
require spurious transposes which are another thing that APL doesn't
exactly do instantaneously. Efficient use of stride-oriented routines
from APL requires some intriguing juggling and often extra data
movement and copying. And why must this stuff get re-examined when you
port your APL to a machine where the addressing and calling conventions
are not the same? You try writing 13 versions of quadNA. Not me.

Then there is the issue of quad divide itself. The days of dense 
matrices are long over, and there is a great opportunity for APL.
The concept of the matrix divide primitive is simple and clean, but
it is at odds with the state of the art in numerical linear algebra.
You'd really like to split the call across the factorization and
the solve because that is what you really want mathematically as
well as for the sake of speed. It seems a shame not to add to APL
primitives which could radically improve on it's scope and give
it an edge on all other languages for scientific computing, right
where it has always excelled: matrix operations.
> 
> In general, the issue of primitive vs defined vs external routines
> applies not only to mathematical functions, but to editors, graphics,
> communication, and who-knows-what-else.
> 
> My view:  If another product does something well, and if APL can
> access that product through a reasonable hook, then the hook is
> preferable to adding a feature to APL.
> 
Can't always be done. Frankly, APL is terrible at control-bound code.
Now one very well-understood case of this is minimization of smooth
functions of many variables, (for example the BFGS Quasi-Newton
method with finite difference approximate derivatives). Now you
really can't write a nice version in APL: I'm at a place where I
wrote one myself as a challenge to several of our fairly expert
programmers. (I figured they'd show me how to do it better). Well,
they use my code because it's too disgusting to write it in APL.
Many good versions of this algorithm exist in FORTRAN, so why not
use them? One good reason: The algorithm needs to call the user-supplied
APL function, and as everybody knows, calling APL from FORTRAN is
uh - as IBM puts it "impossible". So I leave this hugely important
example as a lasting testimony to why you either need to tie down
variables in the workspace (an APL philosophical "no-no") or else
let me put stuff I need (structured constructs for low overhead
control flow) in APL. (I think this is an APL philosophy "lose-lose"
situation.)

Your move.

Also: One really cool primitive I'd like to see would be something
like this; 

Let M be a matrix. The diagonal primitive returns the vector of
diagonal elements of M (easy in APL2, a small modification works
in ISO). For example: if M is 3 3 rho iota 9  then the diagonal
primitive returns  7  4 8  1 5 9  2 6  3 . You can write this
function in APL but it'll be too slow, and you won't be able to do the
best part:

Make the dyadic version so the K diagonal M is the Kth diagonal. Then
in APL2 you'd expect to be able to do the selective specification

(K diagonal M) gets V

and have the diagonal assigned IN PLACE and RAPIDLY. The interpreter
can keep a matrix constructed this way as a band matrix until it
comes to something which causes it to densify the matrix. That is, 
if you start with a zero matrix and put diagonals in it, why take up
more space than you need? Then you can make very long band matrices
and allow an equipped APL interpreter to speed up and save space, 
and allow a less complex interpreter to implement it in dense form.
It would be pretty useful to let plus dot times and quad divide in
on the joke, too, else you don't gain much.

Later,
Andrew Mullhaupt