An iterative alternative of the same algorithm:
perm2=: 3 : 0
z=. i.1 0
for_j. 1+i.y do. z=. ,/ (0,.1+z) {"2 1 \:"1 =i.j end.
)
perm=: 3 : 0
if. y do. ,/ (0,.perm&.<:y) {"2 1 \:"1 =i.y else. i.1 0 end.
)
There is very little to choose between them in
terms of time and space. You can make your own
conclusions on which is more transparent.
----- Original Message -----
From: Roger Hui <[EMAIL PROTECTED]>
Date: Tuesday, May 1, 2007 1:13 pm
Subject: Re: [Jprogramming] Moving past the alchemist stage
> > (a) Avoid recursion, unless you are memoizing the results.
>
> I wonder about this one. A recursion whose results
> are atoms (or involve small amounts of data) could
> be inefficient without memoization. Otherwise there
> is nothing much wrong with recursion in J. e.g.
>
> perm=: 3 : 0
> if. y do. ,/ (0,.perm&.<: y) {"2 1 \:"1 =i.y else. i.1 0 end.
> )
>
> perm 3
> 0 1 2
> 0 2 1
> 1 0 2
> 1 2 0
> 2 0 1
> 2 1 0
>
>
>
> ----- Original Message -----
> From: John Randall <[EMAIL PROTECTED]>
> Date: Tuesday, May 1, 2007 10:52 am
> Subject: Re: [Jprogramming] Moving past the alchemist stage
>
> > Geoff:
> >
> > I think sticking to completely tacit is a hard row to hoe: it
> > makes a
> > steep learning curve even steeper. I would begin with explicit and
> > gradually mix in more tacit.
> >
> > There are a lot of things in J that are completely non-obvious
> if you
> > are coming from another language. Here are a few that have
> helped me.
> >
> > (a) Avoid recursion, unless you are memoizing the results.
> >
> > (b) Learn to use the power conjunction, especially in the form
> > f^:g^:_ .
> >
> > (c) Avoid small selections: use #~f whenever possible. I almost
> never> use @. .
> >
> > I have benefited greatly from the J Phrases: they are both
> useful and
> > instructive.
> >
> > When it comes to projecteuler.net, don't be put off by the J
> > solutions. I had exactly the same experience as you: my J code was
> > about 50 times longer and looked nothing like the experts'. I felt
> > stupid. I have learned a lot more since, but I also know that
> > many of
> > the posted solutions are highly polished for brevity or
> efficiency but
> > not transparency.
> >
> > Most of the more difficult problems are set up so that the warmup
> > example can be done naively, but the actual problem requires
> something> better, either mathematically or computationally. For
> example, #146
> > is mathematically easy, but computationally difficult. It took
> me a
> > long time to get a solution that came in under a minute. On the
> other> hand, the most recent problem (#152) is computationally
> easy once you
> > have done the math, which is highly nontrivial. You can tell this
> > from the small number of solutions 4 days after the problem came
> out.> If it were amenable to brute force, there would be more.
> >
> > Best wishes,
> >
> > John
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
