Dan Bron <[EMAIL PROTECTED]> wrote: I find it easier to understand by translating it into English: [EMAIL PROTECTED] ias "u of each v" while u@:v is "u of all v". Sometimes if the correct choice isn't obvious in J, it may be more so in English.
For example: +/@*: is "sum of each square", while +/@:*: is "sum of all squares" (more likely what you want). The difference is moot in verbs with infinite rank, since "each" and "all" mean the same thing when there is only one thing. #@:$ "length of each shape" = #@:$ "length of all shapes" which is just "length of shape" It's also moot when the rank of u is no more than the rank of v's result, especially in cases where u is atomic (like -:@*:) I use exactly the same idiom for & vs &: (and also &. vs &.:) In fact, there is no difference between the English used in &/&: and @/@: since the monads are identical, while the dyads unambiguously have a dyad on the left for &/&: and on the right for @/@: and the English words are usually not ambivalent. For example: +/&:% is "addition table of all reciprocals", while +/@:% is "sum of all ratios" (probably more useful) (and both monads are "sum of all reciprocals") > As a matter of style, I use @: unless I need the result which @ would > provide. > This makes my programs longer, but it saves me thinking (the results of @: > are > rarely surprising; not so for @ ). Plus, it makes uses of @ stand out, > which > is good because those points are usually interesting, and should be given > special > attention. Very true. I tend to do the same (although I may use @ in common cases like @] and @[ - it's a stylistic point i haven't really settled on yet. > PS: Kirk Iverson once explained the difference between @ and @: like > this: > > Whether you use @ or @: reflects how you think about the problem, even if > the > verbs derived therefrom are functionally identical. If you think of the > problem > as an "assembly line", each item passing from one verb to the nexts, then > use @ . If you think of the problem as "batch processing" where the > complete result of one verb is passed to the next for processing, then use > @: > . > > This analogy highlights another difference between @ and @: namely > perfomance. > In cases where the results are functionally identical, the performance may > not be, > simply because of the overhead of initializing the left verb multiple times. J is, at its heart, an array processing language. As such, it works best on arrays, rather than smaller pieces. It's much easier for the interpreter to take a task given to an array and then chop it into smaller pieces as it sees fit, than for it to see many smaller subtasks and try to intuit that these can be batched together for efficiency. Because of this, for phiosophical reasons (rather than just details of the current implementation), operations involving entire arrays (and hence @: over @) ought to be preferred. I learned this rather painfully as a result of writing my very first APL program - to play Conway's Game of Life. I was still steeped in the Fortran mentality, so my program consisted of two nested loops, iterating one cell at a time (and having 9 separate conditions based on whether a cell was in the middle or in a corner, or on an edge). Later, when I learned to think in terms of arrays, the process was simplified into a sequence of array operations, and all the edge conditions were eliminated by simple use of rotations. > That is, if you think of the solution in terms of @ , don't write it in > terms > of @: just because you find it faster. If you do that without mentioning > it, > then the @ form will never be optimized, which is potentially a loss for > the language. It seems that Roger adds certain basic optimizations, he often does so to sevaral equivalent cases (like u@:v [EMAIL PROTECTED] u&:v u&v [:uv etc.) whenever the differences are largely a matter of syntax rather then semantics, and the same internal code would be invoked anyway. Optimization often works hand-in-hand with coding work-arounds. If vast performance improvements can be obtained by using @: rather than @ it makes sense to just do that rather than to change the interpreter to handle @ in most cases; this is also likely the result that in such cases "thinking about the problem" in terms of @: will likely make just as much sense as @. Think of assembly lines where they make small things like candies or cookies - while the items are on a conveyor belt, there are usually dozens of them side-by-side on the same belt being operated on simultaneously. Hence, atomic verbs like + that while rank 0, actually operate on entire arrays at once (via built-in rank handling code), and were originally of infinite rank in earlier versions of J. -- Mark D. Niemiec <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
