Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!deimos.cis.ksu.edu!ux1.cso.uiuc.edu!tank!trillian!jeff From: jeff@trillian.uchicago.edu (Jeff Adler) Newsgroups: comp.lang.apl Subject: Re: Syntax for extended matrix operations Keywords: APL primitives, beyond quad-divide Message-ID: <6510@tank.uchicago.edu> Date: 2 Dec 89 01:00:20 GMT References: <539@s5.Morgan.COM> <6458@tank.uchicago.edu> <558@s5.Morgan.COM> Sender: news@tank.uchicago.edu Reply-To: jeff@zaphod.uchicago.edu (Jeff Adler) Organization: Department of Mathematics, University of Chicago Lines: 132 In article <558@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: >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? > >Well for one thing, most of those wonderful FORTRAN oriented libraries >require spurious transposes [...] >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. Are you porting APL code or the APL interpreter? If the former, then the vendor should handle this. (I realize that currently only one implementation of APL has quadNA. But if you're going to ask other implementors to add more matrix functions, why not ask them to add quadNA?) If the latter, see my proposal further below. > [...] 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. > >> 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 [...] >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 > [...] > >Your move. Ok, I see your general point. I don't think your example contradicts my point, though. Rather, you've shown that reasonable hooks don't always exist. But maybe better ones can be found. More on that below. In the meantime, you propose adding these functions as primitives. But if we added every useful matrix function that anyone considers basic, we'd have a proliferation of new primitive functions, all of which would be useless to those not doing matrix algebra. (BTW: doesn't it seem a little bit strange that every ISO-conforming interpreter, no matter how dinky the machine it runs on, must provide the gamma and matrix inversion functions?) Instead of primitives, we could add "magic" functions (or operators, in your case), like IBM's POLYZ. Objection #1: "We" can't do that. The vendor has to do that. Answer: True. Just like a primitive. Objection #2: Unlike primitives, magic functions aren't available unless you )COPY them into your workspace. Answer: C has standard libraries of useful things which are not part of the language. To use them, you must explicitly "include" them. Maybe APL should have a standard library. Objection #3: If you are porting to Brand X APL, which doesn't support the standard library, then you're sunk. Answer: If Brand X doesn't support all the matrix primitives, then you're in the same situation. Objection #4: Magic functions are a form of cheating. Answer: I agree. Finally, here's an idea for a better 'hook'. Actually it's not really a hook, since the functions you call have to be specially written to be called from APL. Also, it depends on the interpreter being constructed in a certain way. But the facility described below allows one to write one's own magic functions, and allows the vendor to provide source code for the standard library, making it portable. Suppose you had a facility which was a cross between APL2's quadNA and Dyalog APL's auxilliary processors. The latter are programs (typically written in C) which set up associated functions in the workspace, and which communicate with the interpreter through those functions, not through shared variables. An AP always receives APL data in the form of a C structure (of a predefined type, called ARRAY), which contains information about shape, rank, type, etc. I believe that the Dyalog interpreter itself represents arrays in this way. Thus, no data conversion takes place between the interpreter and the AP. Also, the AP is just as portable as the interpreter itself. If the vendor makes slight changes to the internal representation of data, then it is only necessary to change the definition of ARRAY, and APs will still compile correctly. If the vendor provides a new APL data type (sparse matrix, maybe?) a properly written AP should be able to handle it correctly (though not necessarily efficiently) after being recompiled. quadNA currently allows one to call functions which have access to the internal representation of their arguments, but the functions have to be written in assembler. What I've described above is similar, except that one can use a higher-level language. You also want to be able to pass functions as operands. This sounds like a feasible extension of the Dyalog scheme. If we are to call functions from APL2 in this way, then IBM needs to supply another 'associated processor.' Then we can use quadNA. Objections, arguments, and criticism welcome. >Also: One really cool primitive I'd like to see would be something >like this: [description of "diagonal" primitive]. I agree. --------------------------------------------------------------------------- Jeff Adler jeff@zaphod.uchicago.edu Math Department jeff%zaphod@gargoyle.uchicago.edu University of Chicago jda3@tank.uchicago.edu