[this is my second attempt at sending - my first attempt at sending seemed to succeed, but gmail later declared that this was still a draft.]
On Sun, May 26, 2013 at 8:48 AM, Olivier N. <[email protected]> wrote: >> In Elton Wang's implementation, I can see one trivial change that might help: >> >>> +/+/+/(57=x+/y+/z)*x</y*y</z >>> Where x=.y=.z=i.29 >> >> could instead use >> +/,(57=x+/y+/z)*x</y*y</z > > Oh yes, good point. > Is there a way to test resource (cpu, mem, time) usage within J? Yes. We traditionally use ts=: 6!:2, 7!:2@] which performs instrumented experiments, tracking the time and the space used. (These will be separate experiments). See also http://www.jsoftware.com/help/dictionary/dx006.htm http://www.jsoftware.com/help/dictionary/dx007.htm ts 'i.1e6' 0.000755 8.38989e6 100 ts 'i.1e6' 0.00059935 8.38989e6 100 ts 'i.1e6' 0.00057954 8.38989e6 100 ts 'i.1e6' 0.00059952 8.38989e6 ts 'i.1e6' 0.000714 8.38989e6 ts 'i.1e6' 0.000719 8.38989e6 The left argument specifies the number of timing experiments to perform. That said, note that a stricter version would be st=: 7!:2@] , 6!:2 This is stricter because J evaluates right to left, and this rephrasing allows the timing test to be performed first (capturing warm-up times in the first experiment). That said, it's not very meaningful to run timing experiments only once, so an even better version might be: sTTTtt=: 7!:2@], 6!:2, 6!:2, 6!:2, 6!:2@], 6!:2@] This is a bit arbitrary, and takes at least six times as long as the original sentence (or 3+3*x times as long when a left argument x is supplied), to run (so in tedious cases some patience would be needed), but it addresses many of the common mistakes people can make when reporting benchmark results. >> or, if you prefer >> +/,((57=[+/+/)*[</]*</)~i.29 > > That was a huge step for me. Thanks for pushing me! > > As I understand it, you first use the fact that x equals y equals z > (don't know yet how to represent it correctly in J) then you replace > z with [ and ]. That's the main difficulty for me as it changes the > structure from something linear (reading-wise) to embedded trains. Yes. I'll include a 9!:3]6 display of that train, since I think that helps when learning: 9!:3]6 ((57=[+/+/)*[</]*</)~ ((57 = ([ (+/) (+/))) * ([ (</) (] * (</))))~ In contrast: 9!:3]5 ((57=[+/+/)*[</]*</)~ ((57 = [ +/ +/) * [ </ ] * </)~ > Then I tried to create the corresponding function and used @ > (or should I use @: … rank usage is not perfectly clear for > me yet) creating new forks to avoid an unwanted one: > > fun =: +/@,@((57=[+/+/)*[</]*</)~@i. @ and @: are equivalent when their right argument is a train, because the rank of a train is infinite. > (9!: helped me to check I did it right, thanks!) > > I was surprised a few times by this expression: > > 1. the ~ applies to the whole left fork > instead of just to the parentheses! I am not sure of the distinction you are drawing here, but I will note that the parenthesis is a notation for indicating that the thing inside the parenthesis is an evaluated result that has some independent existence. So v~ means that the single argument definition of v (J calls this monadic, for historical reasons, but Haskell has popularized a different definition of "monadic" so I will try to avoid the term when I am talking to someone and I do not know whether their J, Haskell or musical backgrounds are strongest). However, here, what I called 'v' is a fork and the tines of a fork both get the same arguments. So both of the parenthesis in the original definition denote verbs which see the same arguments (z is the left and the right argument). So this means that I can take the 9!:3[6 rendition of the verb and remove only parenthesis for verbs which see some different argument - the redundant parenthesis are, after all, only for emphasis: ((57 = ([ +/ (+/))) * ([ </ (] * (</))))~ Do you see what I did there? (I removed parenthesis around the middle tines of some forks.) That said, this looks very complicated to me (the many parenthesis mean I stop and think about each one as an independent entity). Going back to the simpler definition (at least from my point of view): ((57 = [ +/ +/) * [ </ ] * </)~ ...here, I "just know" that in a train every odd verb (counting from the right) sees the same arguments. The even verbs are "combining verbs" and so of course each see something different. I have been thinking about how to build a UI which expresses some of these concepts but I've not yet decided how I would want to handle the general cases (specific instances are always so much simpler). > 2. at first I thought I should add a & so that I got > (57&=[+/+/) but it didn't worked as expected Correct. Here you have replaced the fork (57 = _:) with the hook (57&= _:) > 3. is there a reason to use [ *and* ] instead of only ] ? Yes, and this is related to why I added a ~ to the sentence. The combining verb </ needs a copy of z and its right argument is going to be a different result. That said, the other [ was only for emphasis. >> (It's interesting to think about why I used [</] instead of </ > > I tried to understand. Is it because the form with [</] is > equivalent to rank 3 “z </ z * (z</z)” but </ only leads > to rank 2 “(z</z) * (z</z)”? I think you should take another look at the relevant parenthesis in the 9!:3]6 instance of the train. (Does this help?) > I'm still trying to convert it to a function I could use directly: > > nfun 57 > > This seems a good exercice but might take me some time to solve. Your 'fun' is a good start, fun 29 gives you the right answer. So now you just need to do something to convert 57 to 29. And, I think that that thing is: divide by 2 and find the next higher integer. (Does that help?) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
