I can think of several things here: 1) Efficiency does not matter to most people as much as getting things right does,
2) Efficiency is about avoiding doing unnecessary things. 3) There are many efficiency issues --------------- People who are concerned about efficiency need to learn to benchmark, and generally speaking need to learn to focus on correctness first and where efficiency is a problem need to learn to remove the unnecessary parts of the system. More generally, there's also something of a habitual need for documentation. This requires an audience to be writing the documentation for, and requires audience feedback. There's always going to be issues, though... Thanks, -- Raul On Sat, Jan 16, 2021 at 9:53 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
