Arnab, Henry’s explanation below should be really helpful. When I learnt rank it also helped me to see what happens with rank slicing up the left and right arguments.
I add some (hopeful) clarity here that may help using the + primitive again to show how rank can provide looping constructs between the arguments … ]a=. i.3 4 0 1 2 3 4 5 6 7 8 9 10 11 100+a NB. Add 100 to every element of a (+ does this natively) 100 101 102 103 104 105 106 107 108 109 110 111 100 200 300 + a NB. But ‘frames’ are also used to line up to slice arguments so the “3 frames” in each argument (3 items in left, 3 rows in right) produce this result 100 101 102 103 204 205 206 207 308 309 310 311 100 200 300 +"0 _ a NB. Rank allows us to now explicitly along a cell in the left argument (using rank 0) with the *whole* of the right argument <a> (using rank _ infinity) 100 101 102 103 104 105 106 107 108 109 110 111 200 201 202 203 204 205 206 207 208 209 210 211 300 301 302 303 304 305 306 307 308 309 310 311 100 200 300 +"0 1 a NB. This case mirrors the second example above (that was done within frames by the engine) … each cell is added to each row (3 frames) using expect rank 100 101 102 103 204 205 206 207 308 309 310 311 100 200 300 400 +"0 1 &. |: a NB. This shows how we might now add cells to columns, by transposing, applying row-wise, then transposing back 100 201 302 403 104 205 306 407 108 209 310 411 I hope this does not confuse, but playing with examples as per above should help you understand the rank operator more clearly (and how it slices the data, potentially in both arguments in the dyadic case). HTH, Rob > On 17 Jan 2021, at 1:52 pm, Henry Rich <[email protected]> wrote: > > Well explained! What you say makes perfect sense. Now, what can we do to > help people stop doing that? > > Abstractly, specifying rank u"n is simply an instruction to JE to chop up the > arguments into pieces of rank(s) n before applying u. For general u, JE does > exactly that. Thus "n is a directive to execute a certain loop. It is not > merely informational. > > [Implicitly, every verb has a rank. Presented with an argument larger than > its verb rank, the verb will chop up its arguments.] > > The implementation problem is that executing a verb u has a certain overhead > because of the nature of interpreters: arguments have different types, > results have types and shapes, they all have to coexist: starting u and > assimilating its result takes a few dozen clock cycles. If u executes on one > lousy atom, it's finished in 1 clock cycle, and almost all the CPU time is > spent in overhead. > > The solution to this problem is Integrated Rank Support (IRS). When a verb > supports IRS, it warrants to JE that it will take care of a rank if given. > JE will skip the chopping-up step, trusting the verb to create the right > result. All the usual arithmetic verbs, and several others, have IRS. > > When you write a + b, JE passes a and b to the + verb. Even though its rank > is 0, + knows better than to chop up the arguments into atoms: instead it > processes them as vectors, repeating a short-frame argument if needed. > That's IRS for you: even though the verb has nominal rank 0, it can use the > SIMD instructions. The result is AS IF the processing were at rank 0. > > When you write a +"1 b or a +/ b, JE does even more for you. JE notes that + > supports IRS, so it avoids the explicit chopping-up step and passes a and b > to + . + now has more work to do: rather than just repeating a short > argument, it must also repeat over inner cells, with 4 nested loops. If you > perversely write +"0, JE will set up the 4 loops, then see that two are > nugatory, and revert to just one or two loops. > > > > What's the practical effect of all this? You provided a great example by > pointing out that it makes perfect sense to think of scalar and vector > addition as different operations. What the beginner needs to do is note that > the rank of + is 0, which means that if you want scalar addition you don't > need to write +"0: + means the same thing. The added "0 might seem harmless, > or even useful for documentation, but it does add to the interpreter's work. > If you are adding vectors, write +"1 only when it would give different > results from +"0, that is, when you have one vector to add to an array of > vectors. > > The apparent anomaly of sin is because of the details of the & and o. > primitives. o. has rank 0 with IRS, but m&o. is defined as having infinite > rank (with IRS). So yes, sin has infinite rank. But because it's a monad, > it produces the same results no matter what its rank: there is no extension > of a short argument. > > Henry Rich > > > > > > which knows to repeat an argument that > > > > On 1/16/2021 8:59 PM, Arnab Chakraborty wrote: >> Thanks for the lively discussion, much of which I could not follow, though, >> owing to my ignorance about rank integration. >> >> However, I understand that some sort of efficiency issue is involved. >> >> BTW, I can answer one question that even Henry could not answer (for a >> change): why beginners write things like +"0 and sin"0. >> >> They (read "we") are confused by ranks, and the closest concept familiar to >> them is that of dimension of domain. For instance, scalar addition is >> different from vector addition. So +"0 is scalar addition, and +"1 is >> vector addition. This habit is further encouraged by the apparently >> inconsistent rank system of J, like *: having rank 0 while sin has rank >> infinity. But both are functions from IR to IR. Not sure what is happening >> internally, they prefer to explicitly "specify the domain." >> >> Indeed, before this email thread, it never occurred to me that rank is >> somehow linked with efficiency. I just considered a function's rank to be a >> property that is competely dictated by the math of the function. >> >> >> >> On Sun, 17 Jan 2021, 06:46 Henry Rich, <[email protected]> wrote: >> >>> I can't answer that, but I can assure you that they do. >>> >>> Henry Rich >>> >>> On 1/16/2021 7:38 PM, bill lam wrote: >>>> I didn't mean to change stdlib sooner or later, but if we do it again, >>> rank >>>> 0 should be a better option. >>>> >>>> Why users (beginner or not) would write a+"0 b or sin"0 ? >>>> >>>> >>>> >>>> On Sun, Jan 17, 2021, 8:20 AM Henry Rich <[email protected]> wrote: >>>> >>>>> I would be happy for a user to do that, but changing stdlib might not be >>>>> a good idea. Beginning users often write >>>>> >>>>> a +"0 b >>>>> >>>>> and it doesn't cost them dearly. If you make the change, sin"0 will be >>>>> expensive. >>>>> >>>>> Henry Rich >>>>> >>>>> On 1/16/2021 7:17 PM, bill lam wrote: >>>>>> Thanks. then defining sine as 1&o."0 should be fine. >>>>>> >>>>>> On Sun, Jan 17, 2021, 8:07 AM Henry Rich <[email protected]> wrote: >>>>>> >>>>>>> What makes them efficient is IRS. 1&o. supports IRS; 1&o."0 does not. >>>>>>> Is you define sin as 1&o."0, sin will run fast, but sin"0 will not. >>>>>>> >>>>>>> Henry Rich >>>>>>> >>>>>>> On 1/16/2021 6:24 PM, bill lam wrote: >>>>>>>> IIUC All atomic math functions are rank 0 but support IRS so that >>> they >>>>>>> are >>>>>>>> as efficient as rank infinity on long array arguments. >>>>>>>> >>>>>>>> The question should be that >>>>>>>> is 1&o."0 as efficient as 1&o. on long arrays. >>>>>>>> >>>>>>>> On Sun, Jan 17, 2021, 12:32 AM Henry Rich <[email protected]> >>>>> wrote: >>>>>>>>> Terminology. If verb v has IRS, it can handle v"n internally >>> without >>>>> a >>>>>>>>> rank loop. >>>>>>>>> >>>>>>>>> + has IRS. +"n does not need a rank loop. >>>>>>>>> >>>>>>>>> +"n does not have IRS. +"n"n2 does need a rank loop. >>>>>>>>> >>>>>>>>> +/@:*"1 has IRS, but +/@:* does not - that's how they're coded. >>>>>>>>> >>>>>>>>> 1&o."0 does not have IRS. >>>>>>>>> >>>>>>>>> Henry Rich >>>>>>>>> >>>>>>>>> On 1/16/2021 11:27 AM, bill lam wrote: >>>>>>>>>> but the verb in this question is >>>>>>>>>> (1&o.)"0 >>>>>>>>>> >>>>>>>>>> even if 1&o. has IRS, does (1&o.)"0 also has IRS ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Jan 17, 2021, 12:02 AM Henry Rich <[email protected]> >>>>>>> wrote: >>>>>>>>>>> m&v does have IRS if v does. I didn't know that until I just >>>>> checked. >>>>>>>>>>> Henry Rich >>>>>>>>>>> >>>>>>>>>>> On 1/16/2021 7:10 AM, bill lam wrote: >>>>>>>>>>>> I'm not sure if 1&o."0 has IRS (integrated rank support) or not. >>> If >>>>>>> it >>>>>>>>>>>> doesn't then I think the phase with infinity rank is fine. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jan 16, 2021, 7:02 PM Arnab Chakraborty < >>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>> >>>>>>>>>>>>> Just wondering if the correct defn of sin shouldn't be >>>>>>>>>>>>> >>>>>>>>>>>>> sin=:1&o."0 >>>>>>>>>>>>> >>>>>>>>>>>>> instead of >>>>>>>>>>>>> >>>>>>>>>>>>> sin=:1&o. >>>>>>>>>>>>> which has rank infinity. >>>>>>>>>>>>> >>>>>>>>>>>>> With the rank infinity definition +/@sin behaves just like >>> +/@:sin >>>>>>>>>>>>> But, ideally, +/@sin 4 5 should be a list of two numbers, while >>>>>>>>> +/@:sin >>>>>>>>>>>>> should be their sum. >>>>>>>>>>>>> >>>>>>>>>>>>> Just like, +/@*: and +/@:*: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks and regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Arnab >>>>>>>>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>> For information about J forums see >>>>>>>>> http://www.jsoftware.com/forums.htm >>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> For information about J forums see >>>>>>> http://www.jsoftware.com/forums.htm >>>>>>>>>>> -- >>>>>>>>>>> This email has been checked for viruses by AVG. >>>>>>>>>>> https://www.avg.com >>>>>>>>>>> >>>>>>>>>>> >>>>> ---------------------------------------------------------------------- >>>>>>>>>>> For information about J forums see >>>>>>> http://www.jsoftware.com/forums.htm >>>>> ---------------------------------------------------------------------- >>>>>>>>>> For information about J forums see >>>>> http://www.jsoftware.com/forums.htm >>>>>>>>> -- >>>>>>>>> This email has been checked for viruses by AVG. >>>>>>>>> https://www.avg.com >>>>>>>>> >>>>>>>>> >>> ---------------------------------------------------------------------- >>>>>>>>> For information about J forums see >>>>> http://www.jsoftware.com/forums.htm >>> ---------------------------------------------------------------------- >>>>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>>> -- >>>>>>> This email has been checked for viruses by AVG. >>>>>>> https://www.avg.com >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>>> ---------------------------------------------------------------------- >>>>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>>> -- >>>>> This email has been checked for viruses by AVG. >>>>> https://www.avg.com >>>>> >>>>> ---------------------------------------------------------------------- >>>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >>> -- >>> This email has been checked for viruses by AVG. >>> https://www.avg.com >>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
