Re: Odd Ball Challenge

[TedPride]

Actually, pathfinding is doable, if you optimize properly. Work out from both sides, not just one; eliminate all paths that arrive at a node (intersection) reached with a better time; put on hold the x% of paths with the worst distance / time ratio. What you end up with is more or less a diamond area connected on opposite points by the start and end of the path, with every intersection inside the area being a node, and the maximum number of paths corresponding roughly to the surface area of the diamond plus the distance through the middle of the diamond. This is workable, assuming the distance you need to cover isn't more than 10 miles or so, and if it is, you can modify the path to travel into three segments, with the middle segment being travel on trunk lines, of which there are few

This would be much more efficient if programmed in C / C++, however. Perl is a memory hog.

[etcshadow]

Oh, certainly. I never intended to imply otherwise. There are two things, there, though: 1) you're talking about a good bit of intelligent optimization (removing redundant paths through the same point, for example), and 2) there's an existing hueristic (the distance/time ratio, and so on).

Likewise, there's a lot of work that's gone into other known search-space problems. Adversarial strategy (like playing chess), for example has had a ton of work poured into it. There's the so-called "A*" algorithm, which employs some interesting pruning techniques against the search tree. That, of course, has to employ a huersitic function, again (generally some sort of "scoring", like in chess you could add up the point values of all your pieces and subtract the point-values of all of your opponent's pieces). It also makes use of some interesting properties of adverserial strategy, such as the fact that your opponent will not willingly choose a move that allows the possibillity of an exceptional counter-move on your part.

Anyway, the point I meant was: I don't have a good optimization to use against this (and I gave an example of how this is similar to some other AI problems that do have interesting optimizations). Part of what gets in the way is the lack of some sort of helpful heuristic. That is, I haven't yet thought of a good way of representing (as a mathematical function applied against a stage of the algorithm) that an algorithm is likely to "contain more information", in such a way that it doesn't "cheat" and impose my foreknowledge of the answer on the problem :-)