brean / python-pathfinding

Implementation of common pathfinding algorithms
https://brean.github.io/svelte-pyscript-pathfinding
MIT License
316 stars 64 forks source link

Correctness on :Advent of Code problem #52

Closed Markopolo141 closed 10 months ago

Markopolo141 commented 10 months ago

Hello, I thought I would use this python pathfinding algorithm to solve the advent of Code problem this year (https://adventofcode.com/2023/day/17)

unfortunately seems to have a bug:

The following code just sets up the Graph:

3215453535623
3255245654254
3446585845452
4546657867536
1438598798454
4457876987766
3637877979653
4654967986887
4564679986453
1224686865563
2546548887735
4322674655533'''

data = B.split("\n")
h = len(data)
w = len(data[0])
data = [[int(dd) for dd in d] for d in data]
data = list(map(list,zip(*data)))
from pathfinding.core.graph import Graph
from pathfinding.finder.dijkstra import DijkstraFinder

edges = []
for x in range(w-1):
    for y in range(h):
        for i in range(2):
            edges.append([f'x{x}_y{y}_r{i}',f'x{x+1}_y{y}_r{i+1}',data[x+1][y]])
        for i in range(3):
            edges.append([f'x{x}_y{y}_u{i}',f'x{x+1}_y{y}_r0',data[x+1][y]])
            edges.append([f'x{x}_y{y}_d{i}',f'x{x+1}_y{y}_r0',data[x+1][y]])
for x in range(w):
    for y in range(h-1):
        for i in range(2):
            edges.append([f'x{x}_y{y}_d{i}',f'x{x}_y{y+1}_d{i+1}',data[x][y+1]])
        for i in range(3):
            edges.append([f'x{x}_y{y}_r{i}',f'x{x}_y{y+1}_d0',data[x][y+1]])
            edges.append([f'x{x}_y{y}_l{i}',f'x{x}_y{y+1}_d0',data[x][y+1]])
for x in range(1,w):
    for y in range(h):
        for i in range(2):
            edges.append([f'x{x}_y{y}_l{i}',f'x{x-1}_y{y}_l{i+1}',data[x-1][y]])
        for i in range(3):
            edges.append([f'x{x}_y{y}_u{i}',f'x{x-1}_y{y}_l0',data[x-1][y]])
            edges.append([f'x{x}_y{y}_d{i}',f'x{x-1}_y{y}_l0',data[x-1][y]])
for x in range(w):
    for y in range(1,h):
        for i in range(2):
            edges.append([f'x{x}_y{y}_u{i}',f'x{x}_y{y-1}_u{i+1}',data[x][y-1]])
        for i in range(3):
            edges.append([f'x{x}_y{y}_r{i}',f'x{x}_y{y-1}_u0',data[x][y-1]])
            edges.append([f'x{x}_y{y}_l{i}',f'x{x}_y{y-1}_u0',data[x][y-1]])

edges.append(["start",f'x1_y0_r1',data[1][0]])
edges.append(["start",f'x0_y1_d1',data[0][1]])
edges.append([f'x{w-1}_y{h-1}_r0',"end",0])
edges.append([f'x{w-1}_y{h-1}_r1',"end",0])
edges.append([f'x{w-1}_y{h-1}_r2',"end",0])
edges.append([f'x{w-1}_y{h-1}_d0',"end",0])
edges.append([f'x{w-1}_y{h-1}_d1',"end",0])
edges.append([f'x{w-1}_y{h-1}_d2',"end",0])
graph = Graph(edges=edges, bi_directional=False)

where the aim is to find the shortest least-cost path from node "start" to node "end" the pathfinding algorithm Dijkstra's can be implemented by:

finder = DijkstraFinder()
path, _ = finder.find_path(graph.node("start"), graph.node("end"), graph)
path_cost = sum([graph.calc_cost(path[i],path[i+1]) for i in range(len(path)-1)])

which gives incorrect result (of 138). whereas a handcoded algorithm on the same graph gives correct result: (of 102)

for g in graph.nodes.values():
    g.f = float("inf")
open_list = [graph.node("start")]
open_list[0].f = 0
while len(open_list)!=0:
    node = open_list[0]
    if node==graph.node("end"):
        break
    neighbors = graph.neighbors(node)
    for n in neighbors:
        if not n.closed:
            m = node.f + graph.calc_cost(node,n)
            if m < n.f:
                n.parent = node
                n.f = m
            if n not in open_list:
                open_list.append(n)
    node.closed = True
    open_list = open_list[1:]
    open_list.sort()
path = []
while node is not None:
    path.append(node)
    node = node.parent
path = path[::-1]
path_cost = sum([graph.calc_cost(path[i],path[i+1]) for i in range(len(path)-1)])

I am not sure what is going on. perhaps I have missed some warning about proper usage?

brean commented 10 months ago

Very interesting! I think this can also be solved using a Grid instead of a Graph, the feature of a weighted graphs is already implemented. However we have just one very basic test for it.

Testing this with the advent of code example also does not work:

from pathfinding.core.grid import Grid, build_nodes
from pathfinding.finder.dijkstra import DijkstraFinder

B = '''2413432311323
3215453535623
3255245654254
3446585845452
4546657867536
1438598798454
4457876987766
3637877979653
4654967986887
4564679986453
1224686865563
2546548887735
4322674655533'''

g = Grid(matrix=B.split('\n'))

finder = DijkstraFinder()
path, _ = finder.find_path(g.node(0, 0), g.node(12, 12), g)
print(g.grid_str(path=path, show_weight=True))

Sadly I don't have time now. I will have a deeper look at it in the new year

Markopolo141 commented 10 months ago

No worries.

I did a bit of looking, and my impression is that there is something wrong with the way that node.f and node.g are calculated. per finder.py lines 103-112 - but I am not so sure (path-finding isn't my expertise)

        # calculate cost from current node (parent) to the next node (neighbor)
        ng = graph.calc_cost(parent, node, self.weighted)

        if not node.opened or ng < node.g:
            node.g = ng
            node.h = node.h or \
                self.apply_heuristic(node, end) * self.weight
            # f is the estimated total cost from start to goal
            node.f = node.g + node.h
            node.parent = parent

so for each node its 'g' value is the least distance to its parent/s plus one. (I wonder if this is effectively a 'stepest' decent approach) whereas I would normally have thought that 'node.g = parent.g + ng' so that the 'g' value is the smallest sum along the path back to the start node?

brean commented 10 months ago

I had a quick moment to look at this. Still needs more thinking but I like to share some first finds: I wonder why we add the weight that is a fixed value (or 1) in line 109, we also multiply the weight that it costs to move to the next node in the grid.calc_cost function (looks like I forgot to implement this for the graph), so it should be the value from the node we currently look at, I am not sure why we have weight as variable in the finder tbh... For the f = g + h that's actually how it should be for A*, see for example the pseudo-code at wikipedia or the bit more detailed description here: https://medium.com/@nicholas.w.swift/easy-a-star-pathfinding-7e6689c7f7b2 For a pure Dijkstra implementation the heuristic would always be 1, thus node.h would also always be 1... In the calc_cost function of the grid we actually return node_a.g + ng but we don't do that for the graph! Still this does not explain why it doesn't work for my grid-based example.

Next step for me will be to create more unit-tests for the graph-implementation and taking a deeper look at the calacultion of node.g.

brean commented 10 months ago

fixed in 1.0.7, see https://github.com/brean/python-pathfinding/commit/2990b64c99a7f410ca41932ef30219b6c58b3864 also take a look at the new unit test for weighted graphs: https://github.com/brean/python-pathfinding/blob/main/test/test_weighted_graph.py