On Fri, May 24, 2013 at 4:11 PM, Olivier N. <[email protected]> wrote: > Before seeing Elton's new formula I got the sub-optimal > > +/+/+/ (57=x+/y+/z) *. (x</y*/(28$1)) *. (28$1*/y</z) > > That's a lot of ways to compute the same answer. Being new to J, > I was asking myself how do they compare computationally speaking? > Is any of these ways to solve the problem inherently more efficient? > And why?
As a general rule, the more concise your code the faster the result. This is not always true, and can sometimes lead to problems. But eliminating unnecessary complexities can be a good thing. 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 or, if you prefer +/,((57=[+/+/)*[</]*</)~i.29 (It's interesting to think about why I used [</] instead of </ - if you want a hint, use 9!:3]6 though you will probably want to set 9!:3 to something else after you are done, which means reading up on its definition if you are not familiar with it, or restarting J.) But without benchmarking I do not know if that would be faster or slower. It's trading some complexity in the computation with an additional copy of the large data structure representing the tests. On the other hand, for this problem, it may not be that efficiency is important. As for further efficiencies, note that when compared to the perl program this isn't all that inefficient: (+/%#),([</]*</)~i.29 0.149822 About a seventh of the memory being used to represent the intermediate result is relevant to the perl result - this is roughly equivalent to a linked list of linked lists of linked lists. It's not perfectly ideal (and this is not a full accounting of resources) but it's not utterly outrageous, either. You could do what I had suggested earlier and use the fact that z=57-x+y but then you have to run two tests on z (you have to test that it's positive, and you have to test that it is larger than y - I'm assuming that we are already testing that y is larger than x). This is doable, but for this example the potential efficiency gains look bleak - on a modern computer this expression takes too little time to worry about. I hope this helps, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
