Newsgroups: comp.lang.apl
Path: watmath!watserv1!70530.1226@compuserve.com
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Matrix chain product:  FORTRAN vs. APL title bout
Message-ID: <920331064737_70530.1226_CHC146-1@CompuServe.COM>
Sender: root@watserv1.waterloo.edu (Operator)
Organization: University of Waterloo
Date: Tue, 31 Mar 1992 06:47:37 GMT
Lines: 20

In article <1992Mar30.203818.15221@yrloc.ipsa.reuter.COM>,
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes concerning order of
evaluation in multiple matrix products:

 > ... I can DYNAMICALLY decide the best ... ordering for the operation.
 > Now, let's see you do the same in Fortran.  No cheating now:  array
 > sizes are to be determined at run time.

Mmmm.  Unless the shape is known a priori or passed in, FORTRAN hasn't
a clue about the dimensions of a matrix.  So if you're going to allow 
FORTRAN to play in this sandbox, you _have_ to allow shapes to be passed.
Once you do, the game is over:  I pass three arguments in to the FORTRAN
routine:  [1] K, the number of matrices; [2] S, the Kx2 table of shapes;
and [3] V, a vector of the +/x/S matrix entries.  I can then pass pairs of
shapes and pairs of matrices to a standard matrix-product library routine
(by pointing to rows of S and items of V).  It's just work from there on,
proabably not even _too_ hard, modulo determiantion of optimal order.
This might make a good useful external function.


