是时候使用A *算法解决8格滑动难题了

Question

Just wondering if anyone could help me out with some code that I'm currently working on for uni. It's a sliding tile puzzle that I'm coding and I've implemented an A* algorithm with a Manhattan distance heuristic. At the moment the time for it to solve the puzzle can range from a few hundered milliseconds to up to about 12 seconds for some configurations. What I was wanting to know is if this range in time is what I should be expecting?

I've never really done any AI before and I'm having to learn this on the fly, so any help would be appreciated.

Answer 1

What i was wanting to know is if this range in time is what i should be expecting?

That's a little hard to figure out just from the information you've provided. It would help if you could describe how you implemented A*, or if you profiled your application and needed help with specific areas that were slow.

One thing to note that'd probably speed up your average solution time: Half of the starting positions of any n-tile puzzle can never lead to a solution, so you can immediately exclude certain configurations very quickly. For example, you cannot solve an 8-tile puzzle that looks like this:

1 2 3 
4 5 6
8 7 .

To see why, note that because the blank space has to wind up back where it started, the overall number of "up"/"down" moves must be equal, as does the overall number of "left"/"right" moves. That means that the overall number of moves must be even.

But the 7/8 transposition here is one move off from the starting puzzle, without changing the blank position! So this puzzle can't be solved. (However, if we made two transpositions, then it'd be solvable again.)

Answer 2

Like you should know you cannot expect any general time. It depends everytime on the code itself especially in which deap your implementation walkes down the tree and also if your code can use the advantages for processor features.

For debugging I would save or print out (but this takes time!) in which level of your tree you are.

Also remember that the weights are very important. Eg:

123
4 6 <- your final state
789

           213                               1 3
To change  4 6  is much more expensive than  426
           789                               789

I hope that helps.

Answer 3

Obviously, this depends not only on your hardware, but on your implementation. It's not a good measure of performance, though: What you want to do is determine the effective branching factor of your heuristic, vs the actual branching factor of some other non-heuristic approach.

I don't want to say too much more, since this is a homework problem, but if memory serves, Russel and Norvig conver this in the context of the sliding puzzle itself... chapter three, perhaps? (My R+N is not at hand.)