Fork me on GitHub

@cjmurphy so mine didn't work for you?


my map was kind of easy, so I guess I just got lucky


Thanks @bhauman: Yours was the clean one that worked well for the test data and would get into loops for the real data. With some anti-loop code I got G to the top left in 235 steps - but that's too high. And my anti-loop code is just hacky. I don't know why it would work for you and get into recursive loops for me. It is as if I cut and pasted the data and missed a line, or I need to grab a more recent version of your code. Will get back to it next week...


@cjmurphy my data was pretty easy. I'd love to give it a try on your data.


@bhauman: Until now I assumed we all had the same puzzle input. Here's mine:


@cjmurphy so if you pprint (use view-grid with 27 instead of 30 for your data) our two sets of data in grid form you will see that there is one row that blocks the progress. Your row is much higher so my score function fails. The simple thing to do is to have the score function detect if the row is the "wall" row and change its behavior based on wether it's above it or below it.


Thanks @bhauman . I see what you mean about the wall. Mine is on the 3rd row and yours is on 18th row. (post transpose, given your view-grid function does apply map vector, so a row is where all the ys are the same i.e. its really a column).


Well it really is a row in relation to the problem statement


When all the ys are the same it's a row


@cjmurphy Mine didn't read super well but another way to sidestep those conditions is to do two searches. I did one bfs from the beginning to the goal, and then a search for each open space to move it to the point on the first path.