Newsgroups: comp.lang.apl Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!itcyyz!yrloc!rbe From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Subject: Re: what is j? Message-ID: <1991May20.045753.14595@yrloc.ipsa.reuter.COM> Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Organization: Snake Island Research Inc, Toronto References: <199113.993.337@canrem.uucp> <3970007@hpwrce.HP.COM> <1991May18.004902.29060@yrloc.ipsa.reuter.COM> <1991May18.042957.704@yrloc.ipsa.reuter.COM> Date: Mon, 20 May 91 04:57:53 GMT In article rockwell@socrates.umd.edu (Raul Rockwell) writes: >properties. One of my favorite compiled functions, SORTCUT, is an >implementation of '':(+/ @ (<:/) & (>./\) )"1 > >Now, the pre-processor and the main computation are both O(n^2), where >n is the number of elements in a list, but SORTCUT is O(n) :-) >It is true you get speedups from knowing type, rank, etc., but in this >case the big speed ups come from (*) knowing that >. is associative, I think my objection to Roger's use of the term "compiled" might be addressed in a way which also covers your computational complexity argument by a definition of the following nature: Compilation: The process of translating an algorithm expressed in an arbitrary notation into another notation which has execution speed properties which approximate those of hand-written assembler code. Now, there ARE problems with this definition: a. Whose assembler code? b. Assembler code written for a RISC machine, without attention to code-scheduling issues, might execute worse than that resulting from a C compiler. The point I want to make is that I think of compiled code as being something that runs about the same speed as the same algorithm coded in C, the above statement notwithstanding. Ten or a hundred times slower doesn't count. Bob