> Is it one of the things in the table towards the bottom of the J article? Erm, no. That table suggests using b. as a replacement for other (clearer) algorith

> Is it one of the things in the table towards the bottom of the J article? Erm, no. That table suggests using b. as a replacement for other (clearer) algorithms for performance reasons, rather than parameterisation. What I mean by parameterisation is this: if you have a function that takes some arbitrary bitwise operation, instead of taking a lambda, you can pass the truth-table directly. This idea is mentioned only briefly in the J article (More Info, ¶2): 2. Operand m may be an array, in which case each result cell will be the array of the results of the logical functions specified by m. Maybe that is too-obvious to an array programmer and not-enough-obvious to someone who isn't, and so it is hard to properly consider the implications or applications of this. Here's one: Parsing AND/OR operations from an expression (like an SQL expression). You could use a tree of operators and then walk the tree for every row you want to consider or you could store the compositions as a list and do a single reduction. Is that enough for you to get the idea of what is going on here?