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> <ROCKWELL.91May18095711@socrates.umd.edu>
Date: Mon, 20 May 91 04:57:53 GMT

In article <ROCKWELL.91May18095711@socrates.umd.edu> 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

