🚀 go-pugleaf

In <KANZE.95Aug9150340@slsvhdt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James 
Kanze US/ESC 60/3/141 #40763) writes: 

>In article <jbickers.167f@templar.actrix.gen.nz>
>jbickers@templar.actrix.gen.nz (John Bickers) writes:

>|> Quoted from <3vc96g$dnq@caip.rutgers.edu> by halasz@caip.rutgers.edu:
>|> > In article <huang.806961597@nickel.cs.umanitoba.ca>, 
huang@nickel.cs.umanitoba.ca (Hui Huang) writes

>|> > + As to the question of swapping the array, if I haven't seen it before (I saw
>|> > + it in some textbooks), I would check out some algorithm books and see if it

>|> > Maibe, but this is the good engineer s way, for this helps yield the shortest
>|> > time to finishing the job.

>|>     Not if the wheel can be re-invented faster. Hasn't someone already
>|>     mentioned that a solution can be worked out in about five minutes?

>They even posted the solution they worked out.  It didn't work.

I posted a solution that didn't work.  My second solution worked fine.  
Both of them together took me less time than it would have taken _me_ to
look it up and adapt a published solution.  Others might be able to find
such things much quicker.  For someone who found things faster and solved 
them slower, the optimal path might be much different.

Also, while my total time spent was low, my elapsed time was about 16 hours.  
If it was a priority item I could research it faster than that.  On the other 
hand, I was solving it on paper, as if it was presented as an interview question 
with no mechanical aid allowed.  This decreased my speed producing solutions 
because I couldn't depend on an interactive system to point out my typos etc.
Also it eliminated the testing step.  That would have allowed a much faster 
cycle.

I much prefer computer-aided problem solving.