The usual thing to do when you have a recursive routine that needs an IUO parameter, is to use a 'helper' wrapper that supplies it.

Here's a cleaned up and simplified version that does that:

#! perl -slw
#! perl -slw
use strict;
use List::Util qw[ shuffle ];
use Data::Dump qw[ pp ];

my %graph = map {
  ( chr( 64 + $_ ) => [ (shuffle 'A'...'Z')[ 0 .. 1+ int( rand 10 )] ]
+ )
} 1, (shuffle 2 .. 25)[ 0.. int( rand 20 )], 26;

pp \%graph;

sub _findPaths {
    my( $graph, $start, $end, $seen ) = @_;

    return [$end] if $start eq $end;

    $seen->{ $start } = 1;
    map {
        map [ $start, @$_ ], _findPaths( $graph, $_, $end, {%$seen} );
    }  grep !$seen->{ $_ }, @{ $graph->{ $start } };
}

sub findPaths { _findPaths( @_, {} ); }

my( $start, $end ) = @ARGV;

print "@$_" for findPaths( \%graph, $start, $end );

__END__
c:\test>868031 A Z
{
  A => ["M", "L", "V", "Y", "C", "T", "X", "B", "U", "G", "J"],
  B => ["U", "W", "E", "Q", "M", "G", "N"],
  H => ["K", "L", "I", "S", "B", "H", "M", "P", "Q", "N", "T"],
  L => ["Q", "X", "E", "D", "L", "S", "N", "K"],
  P => ["D", "O", "Y", "R", "I", "W", "Q", "V", "N"],
  Q => ["P", "A", "N", "X", "R", "M", "T", "H", "O", "V"],
  R => ["O", "A", "S", "V", "M"],
  T => ["J", "Z", "F", "T", "Q", "X", "S"],
  V => ["L", "E", "Z", "V"],
  Y => ["M", "X", "Y", "I", "K", "U", "G", "S"],
  Z => ["M", "F", "A", "P", "I"],
}

A L Q P R V Z
A L Q P V Z
A L Q R V Z
A L Q T Z
A L Q H P R V Z
A L Q H P V Z
A L Q H T Z
A L Q V Z
A V L Q T Z
A V L Q H T Z
A V Z
A T Z
A T Q P R V Z
A T Q P V Z
A T Q R V Z
A T Q H P R V Z
A T Q H P V Z
A T Q V Z
A B Q P R V Z
A B Q P V Z
A B Q R V Z
A B Q T Z
A B Q H P R V Z
A B Q H P V Z
A B Q H T Z
A B Q V Z
[download]

Be warned. The random tree generator can generate some pretty big results sets.

Dear BrowserUK,
What's the time complexity of findPaths()?
Thanks so much for improving the subtroutine.


---
neversaint and everlastingly indebted.......

What's the time complexity of findPaths()?

Um... O(lots) :). Honestly, I haven't got a clue how you go about assessing that.

It will be entirely dependant upon the complexity of the graph. Not just the number of nodes, but the number of connections at each node. And I don't have the math to make that kind of assessment.

I'd say that if your graphs are big enough for you to worry about it, then you'd probably be better of looking at an iterative solution rather than a recursive. Though often, iterative solutions that just emulate the recursion through manual stack handling are no more efficient, and often much less so.

I think the main cost of my routine is the memory allocations for the results sets. If your application only need to process one results set at a time, rather than having them all available, then I'd be looking for an iterator solution.

FWIW (which is not much IMO), the literature says that breadth-first and depth-first are both O(B^d) worst case.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

If you can do what you need to do with the paths by getting them one at a time, rather than all at once, then this version of findPaths() runs much faster and uses far less memory. (It runs faster because it uses much less memory.)

For example, on a randomly generated graph that has 10,000 paths, it takes 1.09 seconds instead of 38 seconds for my previous version. In the process, this uses less than 7MB where the previous version used 240MB.

And on a graph that has just over 5 million paths, this still uses just 7MB and completes in 14 1/2 minutes.

I project that the previous version would take 5 1/2 hours to complete, except that it would require 12GB to do so, and I only have 4GB.

It's still the same order of complexity--its essentially the same algorithm--but the simple expedient of avoiding allocating and reallocating zillions of small chunks of ram, mean in the real world it is much faster. Which confirms once again my feelings about big O.

Anyway, if your algorithm can be adapted to operate this way, you might find it useful.

sub _findPaths2 {
    my( $code, $graph, $start, $end, $path, $seen ) = @_;
    return $code->( @$path, $end ) if $start eq $end;
    $seen->{ $start } = 1;
    for ( grep !$seen->{ $_ }, @{ $graph->{ $start } } ) {
        _findPaths2( $code, $graph, $_, $end, [ @$path, $start ], { %$
+seen } ),
    }
}
sub findPaths2(&@) { _findPaths2( @_, [], {} ); }

findPaths2{
    print join ' ', @_;
} \%graph, $start, $end;
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

please have a look at this post: Re: Short Circuiting DFS Graph Traversal