Newsgroups: comp.lang.apl
Path: watmath!watserv1!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Matrix chain product:  FORTRAN vs. APL title bout
Message-ID: <1992Apr3.165927.8241@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
References: <920331064737_70530.1226_CHC146-1@CompuServe.COM>
Date: Fri, 3 Apr 92 16:59:27 GMT

In article <920331064737_70530.1226_CHC146-1@CompuServe.COM> Mike Kent <70530.1226@CompuServe.COM> writes:
>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.

At the risk of being rude (something I try to avoid doing by accident),
I think you have entirely missed the point, which is: WHO does the work?

In the case of Fortran, the APPLICATION PROGRAMMER has to:
  a. be aware of the existence of the "useful external function"
  b. be aware that the UEF can help performance
  c. code explcitly to invoke the UEF.
  d. Encounter possible bugs trying to invoke UEF.
 and so on.

In the case of APL:

a. Arrays are self-describing, and it is impossible to get the shape of
   an array wrong(assuming a working interpreter/compiler). Since Fortran 90
   has discovered that arrays exist along with their bounds, this is
   not a strong difference. 

b. The compiler/interpreter writer, NOT the application programmer, does
   the work required to determine the optimal order of application.

c. The application programmer merely does a matrix product reduction,
   or does a sequence of matrix products, as usual. If the interpreter
   has the UEF under the covers, it will take advantage of it. If 
   the UEF doesn't exist, no one is the wiser, and things continue to work,
   albeit slower.

The whole point of all this is to hide superfluous detail from the  
applications programmer, who should (properly) be thinking about 
the problem space, not how to make fast code. The fast code is
properly left to the system, as in APL, where primitives such as 
grade(sort), set membership, table lookup, matrix multiply, etc., 
are optimized to such a degree that no sensible user ever thinks of
coding a user-defined one. 

Furthermore, when interpreter code improves (as it does on almost
any commercial system which intends to stay in business), all 
appications immediately speed up, whereas user-coded primitives
or UEF's do not speed up.

It's a division of labor, and Fortran is simply too primitive to
support a proper division.




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
