Yes, that may be worthwhile. A good project for one of your bright students?
On Mon, Oct 17, 2011 at 12:45 PM, Henry Rich <[email protected]> wrote: > > - There is special code for anything worthwhile that you can think of. > > The one I wish for is ;@:(<@u) > > Henry Rich > > On 10/17/2011 2:34 PM, Roger Hui wrote: >> a. I believe only a very few APL interpreters (if any) would avoid >> making a copy of ,y, if you do x⍴y (x rho y). >> >> b. To get a single number from comparing 3 3⍴⍳2 3 4 against 3 3⍴,⍳2 3 >> 4, you need to use ≡ (match) instead of =. >> >> c. A key idea to remember, is that in J there is no look ahead in the >> parser. So the difference between x$,y and x($,)y, is that for x$,y >> the parser would do ,y, then do the x$ of that. When it does the ,y, >> it doesn't "know" that the next thing it's going to do is $ . In >> contrast, for x($,)y, it first derives a function for the hook ($,) >> and in such derivation "knows" that for the dyad you are doing a >> reshape of a ravel. >> >> d.> I don't think I can memorize everything I will need. >> Don't try to memorize the list. Just remember two things: >> - There is no look ahead (except for a couple of important cases involving >> =:). >> - There is special code for anything worthwhile that you can think of. >> If you find any deviation from the above, report the deviations to the J >> Forum. >> >>> There is a special case in there x (n|@^)y that >>> would have made the solution to the problem instant and trivial, without the >>> @ it takes more than an hour - and that is how I did it, sigh. >> >> I submit that for this example, if you keep the "two things" in mind, >> you coulda/shoulda/woulda have found the special code for x (n|@^) y . >> >> >> >> On Mon, Oct 17, 2011 at 9:50 AM, Nick Simicich<[email protected]> wrote: >>> ts '1 1 1 +./@E. (1 1 1 ,100000$0)' >>> 8.1599503875016434e_5 263936 >>> ts '+./3*./\ (1 1 1 ,100000$0)' >>> 0.00061567625668835938 395072 >>> ts '+./ 1 1 1 E. (1 1 1 ,100000$0)' >>> 0.0003145580874868281 394880 >>> >>> So the phrase +./@E. must have an early out for a single matched pattern. >>> But 3*./\ compares poorly to +./ 111 E. even without the early >>> >>> That is an enormous difference. >>> >>> I found the special code page, thanks to the above, I guess I need to study >>> it if I want to write excellent code. For one thing, had I read through >>> that page, there is one of the euler problems that would have been trivial >>> and short, it was something like computing the last few digits of a large >>> number to a large power. There is a special case in there x (n|@^)y that >>> would have made the solution to the problem instant and trivial, without the >>> @ it takes more than an hour - and that is how I did it, sigh. >>> >>> One thing that bothers me is the first thing in the list: >>> >>> In the old days of APL, one could reshape a structure directly (as an in >>> line result, of course, not as a side effect) with rho. I had noticed that >>> that didn't quite work here. 3 3 $ i. 2 3 4 is not the same as 3 3 $, i. 2 >>> 3 4. Once I learned that it didn't bother me. I had sort of presumed that >>> the difference between a vector and a matrix as an intermediate result might >>> have been nothing more than a flag saying, "this is a vector of L20' without >>> any actual rearranging. (I tried this in NARS2000, and it did not work as I >>> expected it to, but the malfunction is basic, I could not reduce the output >>> of (3 3 rho iota 2 3 4)=(3 3 rho , iota 2 3 4) to a single number no matter >>> how many ravels and compresses I stacked up, it kept displaying 1 1 1. >>> NARS2000 is very ambitious, and is admitted to not be prime time. But the >>> two sides of the expression agreed in shape and numeric value. >>> >>> So I was wrong about J, and there is some rearranging, to the point where >>> ($,) skips the rearranging while $, does not, and this saves some work. >>> >>> ($,) is faster than $, but why would you not always use the "better" code? >>> Why not use the better code any time you see $,? >>> >>> Now I understand that most of these things are only special when they are >>> glued with @ or&. Why is this one special as a hook without glue? Is it >>> because $@, does not have the same semantics as $,? Is this the only phrase >>> that needs to be expressed as a hook to crank up the special code? >>> >>> I'm taken aback by the number of cases that have special case code - some of >>> the code is functional, like the code that doesn't calculate unused parts of >>> the result, and some just seems to be code that was put in to speed things >>> up. I don't think I can memorize everything I will need. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
