Newsgroups: comp.lang.apl
Path: watmath!watserv1!70530.1226@compuserve.com
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Re: Re:  APL execution efficiency revisited
Message-ID: <920322073241_70530.1226_CHC87-1@CompuServe.COM>
Sender: root@watserv1.waterloo.edu (Operator)
Organization: University of Waterloo
Date: Sun, 22 Mar 1992 07:32:42 GMT
Lines: 37

In article <745Akepler1.rentec.com>, andrew@rentec.com (Andrew Mullhaupt)
writes

 >  [Several classic APL dont's omitted]

Classic, but not as well-known or widely understood as one might hope,
if the code I've seen over the last decade is any indication.  The
season-ticketed audience in this venue is _not_ representative of the
APL-programming community overall and much or all of what I wrote 
is old news to them.  Still, you had made some rather general assertions
about APL execution efficiency (or I took your meaning wrong), so I felt
it appropriate to post some advice on solving execution efficency
problems, shopworn though it may be, since following these rules of thumb
will give code which avoids a large number of the worst cases.  And again,
your mileage may vary.

 >>[4] Inner and outer products in which most of the entries are        
       discarded, or used only as intermediates.
 
 > This can be almost impossible to avoid ...

No vendor has yet (so far as I know) optimized

    first plus.times / (vector of matrices)

but it's probably only a matter of time ...   Of course, the idiom would
be unrecognizable in, e.g., C.  One could write a library routine to
handle this in a compiled language, but at many current interpreters,
it's likely that the library routine would be callable (via a []NA-like
interface) from APL.  This is certainly true of APL2.

My point here is that APL code does not, ordinarily, have to be an order
of magnitude (or even a factor of 2) slower than compiled code.  And I am
tired of hearing that this _is_ so, and that it is _inherent_ in the
language.  


