Path: utzoo!mnetor!tmsoft!itcyyz!yrloc!intern
From: loc@yrloc.ipsa.reuter.COM (Leigh Clayton)
Newsgroups: comp.lang.apl
Subject: How the "OVER" construct works
Message-ID: <1991Jan29.194223.7806@yrloc.ipsa.reuter.COM>
Date: 29 Jan 91 22:53:46 GMT
Sender: intern@yrloc.ipsa.reuter.COM (Intern via QUADRAM)
Organization: Reuter:file Ltd.
Lines: 136
X-Telephone:  +1 (416) 364-5361 Fax +1 (416) 364-2910 Telex 0622259
X-Mail:       1900/2 First Canadian Place, Toronto, Canada, M5X 1E3

-----From Peter Biddlecomb, Reuter:file

>no. 4885159 filed 15.15.31  tue 29 jan 1991
>from pbid
>to   clapl
>subj How the "OVER" construct works
>
>
>In response to the request from Rudi Rynders, here's an attempt to explain how
><over> works, concentrating on the bits which APL users are likely to have
>problems with. It does not attempt to explain terms such as 'item' and 'atom'.
>The explanation was arrived at from sevral directions:
>
>(a)  Examining the results of (5!:1 <'over') to get an idea of the work done.
>(b)  Writing my own version in " monad :: dyad " form.
>(c)  Reading the 'Parsing and Execution' section of the Dictionary of J, and
>     the definitions of @ and &.
>
>As there are at least two versions of <over>, let's note the one we're looking
>at and what it does:
>
>      over =. ;@({.;}.)&":@,
>      z over z+/z=.1+i.3
>+-----+
>?1 2 3?
>+-----+
>?2 3 4?
>?3 4 5?
>?4 5 6?
>+-----+
>      t=. z+/z    [ right arg. of over ]
>
>We start by inserting the definition of <over> between <z> and <t>:
>
>     z ;@({.;}.)&":@, t
>
>This of course gives the same result as <z over t>.  <over> does exactly the
>same job as <iota=.i.> - it gives us a name for a sequence of J primitives.
>The causes of bafflement when I try to analyse <over> by eye are:
>
>(i)    large number of primitives - the APL one-liner effect
>(ii)   unfamiliar symbols (and possibly different implementations of the
>       primitives they represent) if you're used to APL
>(iii)  the use of conjunctions - primitives which affect order of execution
>
>Here's <over> divided into meaningful units:
>
>          ;:   'z ;@({.;}.)&":@, t'
>
>+-+-+-+-+--+-+--+-+-+--+-+-+-+
>?z?;?@?(?{.?;?}.?)?&?":?@?,?t?
>+-+-+-+-+--+-+--+-+-+--+-+-+-+
>
> n v c <----v----> c v  c v n     [this line is NOT provided by ;:]
>
>The bottom line categorises the contents of each box as Noun, Verb, or
>Conjunction.  We can mark the fork ({.;}.) as a verb at this stage.
>
>Now we parse the expression.  The crucial point to note is that conjunctions
>are executed before verbs, so we analyze them first to get an expression
>which consists of nouns and verbs.
>  The other point to note is that "the left argument of [a] conjunction is the
>entire verb phrase that precedes it".  So starting with the rightmost
>conjunction and using the same notation for its arguments as the dictionary,
>we have:
>
>        z ; @ ( {. ; }. ) & ": @ , t
>
>        x <--------u---------> @ v y    [ <u> is the verb phrase... ]
>
>the dictionary tells us that  x u @ v y => u x v y: >--+
>                                                       ?
>        <---------u--------> x v y  <------------------+
>
>        ; @ ( {. ; }. ) & ": z , t
>
>        <------u------> & v  <-y->  >------------------+
>                                                       ? u & v y => u v y
>        <------u------> v  <-y->  <--------------------+
>
>        ; @ ( {. ; }. ) ": z , t
>
>        u @ <----v-------> <-y->    >------------------+
>                                                       ? u @ v y => u & v y
>        u <----v-------> <-y->  <----------------------+
>
>        ; ( {. ; }. ) ": z , t
>
>Now we have an expression which tells us what to do with z and t.  The only
>barriers to understanding now are differences in symbols and their
>implementation, and working out what the fork ( {. ; }. ) does. In detail, we:
>
>(a) catenate <z> on top of <t> [equivalent to <,[quad-IO]>]
>(b) format the result [if we didn't do this, our column headers would be
>       misaligned for some values of t.]
>(c) catenate the boxed first item (row in this case) onto the boxed remaining
>    items [note that take and drop operate on "items" rather than scalars]
>(d) convert the result into a one-column matrix
>
>We can write a version of <over> which is easier for me to understand:
>
>   over =. '' :: ';({.;}.)":x.,y.'
>
>Apart from the treatment of the monadic version of <over>, this does just the
>same thing.
>
><by> can be analysed in the same way, but this is left for you to do!
>
>Peter Biddlecombe, REUTER:FILE, London
>

-------And from Roger Hui, Iverson Associates

>no. 4885515 filed 16.27.29  tue 29 jan 1991
>from hui
>to   pbid
>cc   clapl
>subj How the "OVER" construct works
>ref  4885159
>expy  0.00.00   1 mar 1991
>
>Just one comment:  as I pointed out in 4836625, if you simply enter the
>name of the verb, you get a boxed display of the verb.  This display
>tells you J's idea of what squiggle is grouped with what other squiggle,
>ie. very much like a tree, ie. the result AFTER parsing.  This removes
>word formation and syntax from the picture, leaving only the semantics
>to be analyzed (meanings of @, &, ":, etc.).
>
>Of course, this is just another alternative.  The approach taken in your
>msg can be no less valuable.
>
>

-----------------------------------------------------------
loc@tmsoft.UUCP                     uunet!mnetor!tmsoft!loc
loc@ipsa.reuter.COM                         (Leigh Clayton)