Greg Millam wrote:
> As far as we are concerned, there's only one effective connection from
> each edge to the other: the shortest song. You will never go back to
> that node, you will never need to traverse a second song from that node
> to another particular node. And in no instance will a costlier
> connection ever be considered over a cheaper connection connecting the
> two same nodes.

But the shortest path between two songs may not always be the path through
the shortest songs from each song. Example (with made up songs, but I'm
sure this could happen with "real songs"):

Greg's Shortest Path:
---------------------
Hello There, 3:45
Echo It All, 2:34
Live It Up, 3:52
Pour It On, 2:45
No No No, 5:01

True Shortest Path:
---------------------
Hello There, 3:45
Eat a Ton, 5:34
No No No, 5:01

So you really have to traverse all possibilities, keep track of the
current best option, and only short-circuit when the current path exceeds
the best path at that point.

The beauty of this is that the traversal technique never really needs to
change, just the method of determining the best path, and when a path
needs to be short-circuited. So you can easily find the shortest path, the
longest, and the one that most closely fits in a given time slot by just
changing your weighting algorithm (in fact, you could do this all at once,
keeping a "best" for each.)

Damn, now that I think of this, I should go back and actually finish that
Monkey Barrel quiz (I got as far as the XML parsing :)

Ryan