1

I am currently trying to use A* to create cyclical routes (for plotting driving routes of set distances). I want to find a driving route from my start location that is as close to my specified length as possible. If it is bigger or smaller that is fine, just as close as possible

I have therefore adapted the heuristic function to:

|target distance-distance Travelled so far| + distance left to travel.

for example, I want to travel 20 miles, so my target distance is 20. At some point in the route i may have travelled 18. Therefore my h would be 20-18+2 = 2. I always pick the smallest h value, the idea being a route of 20 miles will be created finished where i starts.

I had 2 immediate issues with this.

  1. The Start node can't be added to the closed list immediately or it will never create a cyclical route - I believe I have solved this one.
  2. If the search goes into a cul-de-sac it gets stuck and the openlist becomes empty and the search terminates.

The second problem I cannot think of how to solve. It occurs because the successor node that would get the search out of the cul-de-sac is already in the closed list.

Can anyone help me come up with a general solution to my problem? Furthermore do you for see any other issues with my implementation?

would really appreciate any help you can give.

Programatt
  • 113
  • 3
  • 1
    It's still not clear to me what you're looking for. Is it a closed walk in your graph where the total weight of the edges in the graph is as close as possible to the target? (A walk is like a path in a graph but you're allowed to repeat vertices and and edges; "closed" means that the last vertex is the same as the first.) So, for example, a possible answer might be "drive from $a$ to $b$ and then back to $a$, ten times", assuming nothing was closer to your target? – David Richerby Dec 18 '14 at 14:37
  • Yes precisely! I was hoping the heuristic function I have chosen would discourage such behaviour but this would certainly be acceptable. – Programatt Dec 18 '14 at 14:45
  • OK. In that case, my answer doesn't apply so I've deleted it. It may be possible to do what you want with A* but the search space will be exponential so the algorithm might not be efficient. I'm busy for the rest of the afternoon but I might have time to write another answer later. – David Richerby Dec 18 '14 at 15:09
  • I'd really appreciate that David, thank you. efficiency isn't too important to me at this moment in time as I would just like to get it working. Any help you can give would be really appreciated. – Programatt Dec 18 '14 at 19:35
  • Why have you honed in on using A* for this task? There might be other ways to do it that would be better than A*. Seems like you're getting ahead of yourself. 2. What do you know about the graph? Are all distances integers, or could they be real numbers? What are typical values for the desired length, the number of vertices, and the number of edges? 3. Your problem is NP-hard (by reduction from subset sum), so you shouldn't expect a general-purpose algorithm. So, please read http://cs.stackexchange.com/q/19412/755.
  • – D.W. Dec 18 '14 at 23:43
  • I chose A* because it is an algorithm I knew well, was comfortable with and have already implemented. I will be completely honest, I thought adapting it for my use case would be a lot simpler than it seems. I will of course look at your article. Thanks! – Programatt Dec 19 '14 at 18:55