in reply to Re^3: Better algorithm than brute-force stack for combinatorial problems? (explain)

in thread Better algorithm than brute-force stack for combinatorial problems?

Thanks. It'll probably take a few more readings to take that all in, but on the surface it makes (more) sense to me now. I think I was part way there with understanding the calling syntax and general methodology of the algorithm, but this clarifies it.

The main problem I was commenting upon though is subtly different from understanding how to use NestedLoops. It's more a case of wrapping my brain around how to apply it to any given problem. I guess it is really no more complicated that coding a recursive routine and remembering that each piece of code will be run at all levels, but I've been doing recursion long enough that it has become second nature to think that way. This is like recursion, but different; and without the overhead.

The subtly seems to be to the `$sum[ @_ ] = ...` bit. It took this post for me to realise that `@sum` isn't really an array in terms of the algorithm (the absence of the postfix 's' would be a clue if you normally hold to that convention). It's really a stack of autovivified, level-specific, persistant 'local' storage. (I think!).

I stuck a `print "@sum\n";` before the return in the OnlyWhen routine and it's interesting to watch the values iterate.

This definitely requires a good "cookbook" article (or book?) to stimulate exploration of it's uses and algorithms. If you have the time TPJ were asking for authors:)

"Think for yourself!" - Abigail

Replies are listed 'Best First'. | |
---|---|

Re^5: Better algorithm than brute-force stack for combinatorial problems? (using A::L)
by tye (Sage) on May 22, 2004 at 21:38 UTC |

Comment onRe: Re^3: Better algorithm than brute-force stack for combinatorial problems? (explain)SelectorDownloadCode