Newsgroups: comp.lang.apl
Path: watmath!watserv1!70530.1226@compuserve.com
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: What does that FORTRAN code  _do_?
Message-ID: <920404100728_70530.1226_CHC22-1@CompuServe.COM>
Sender: root@watserv1.waterloo.edu (Operator)
Organization: University of Waterloo
Date: Sat, 4 Apr 1992 10:07:29 GMT
Lines: 75

In article <ROCKWELL.92apr2194843@socrates.umd.edu>
rowkwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) asks:

 > um... but what does the code do?

My apologies ... FORTRAN is so easy to read that I generally neglect to
comment it (ho ho).

Calling

               partsum(count1, count2, lenvec, itmvec, result)

produces a partitioned sum of the integer vector <itmvec> in <result>,
that is, a sum of the <count1> consecutive subvectors of respective
lengths <lenvec>.  It does this a bit more quickly than the usual APL
+\ , compress, first differences idiom with a partitioning bit vector
marking the partitions of <itmvec> when <count1> is very small, and
considerably more _slowly_ when <count1> modest to large (modest == 50).

There are some corrections to the original posting (my memory is
imperfect, alas):  the excess memory accesses were  associated with the
outer loop, and no initialization to zero is required for the items
or <result>, it being assumed that the _caller_ has built a vector of 0's
ahead of time (since the code was written to be called as an APL2 external
function).

  
 * * * * * *


In article <1992Apr3.165927.8241@yrloc.ipsa.reuter.COM>,
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) goes on a bit (politely
enough) about the proper division of labor between applications and
systems software.  I reply:

Mmm, but Bob, you had written "I'd like to see you _do_ that in
FORTRAN" [emphasis mine].  I just wanted to point out that it isn't
all that hard, just mainly tedious.  On reconsideration, I've
reconsidered, though; a truly general solution would have to do some
dynamic memory management, which is far, far, far better left to the
system than handled by the application, at least if _I_ have to write
the code. 

You are of course right that the more the system does for you, without
constraining _your_ options, the better off you are.  I thought, and
still think, that { first +.x / } is not an especially compelling 
candidate for a new primitive, or []MATCHAINPROD, or idiom recognition 
(though I'll give a bit on idiom recognition).  Like a lot of other
problems, it's of vital interest to a lot of people, and of next to no
interest to a whole lot more people.  That's why I think it would be more
useful as an external function ( == library routine ).  On the other hand,
if the idiom recognized were { first f.g / } with identification of the
cases where the pair f::g has an associative inner product and shape-
based ordering of the reduction so that that { and . = / } and a personal
favorite { or . and / } also benefitted for example, THAT would be a real
good candidate for incorporation into the system software, i.e., the APl
interpreter.  On the other other hand, I'd bet a small amount that in most
real cases, long chains consist of odd-shaped members at one or both ends
with the rest of the chain consisting of square matrices so that the
problem is just whether to eat the chain from the left, from the right,
or to compute the square-matrix chain product first and then do a three-
item product optimally.  Those cases can be handled by a rule-of-thumb
which is simple enough to code up in APL -- no need to resort to general
dynamic-programming techniques.  The only time _I_ had to contend with
extensive matrix chain products, the problem involved two-item vectors
with assorted chains of 2x2 matrices in between, and the default
association was optimal (though I didn't worry about it at the time ...
I was only interested in getting the right answers, in a time frame of a
couple of weeks, as I had to form a 12x12 matrix of such products,
average chain length was around 6 or 7, and I was having fits working out
1000 trivial matrix multiplies by hand).

Mike Kent [ who would just as soon _not_ flog the mouldering corpse of
            this dead horse any further ]

