I’ve had 100% failure rate on simple requirements that require a simple spin on well known solutions
“Make a pathfinding function for a 2d grid” - fine
“Make a pathfinding function for a 2d grid, but we can only move 15 cells at a time” - fails on lesser models, it keeps clinging to pulling you the same A* as the first one
“Make a pathfinding function for a 2d grid, but we can only move 15 cells at a time, also, some cells are on fire and must be avoided if possible, but if there is no other path possible then you’re allowed to use fire cells as fallback” - Never works
There for that last one, none of the models give a solution that fits the very simple requirement. It will either always avoid fire or give fire a higher cost, which is not at all a fitting solution
High costs means if you’ve got a path that’s 15 tiles long without fire, but way shorter with fire, then sure, some fire is fine! And if you could walk 15 tiles and go to your destination but need to walk on 1 fire, then it will count that as 15-something and that’s too long.
Except no, that’s not what you asked.
If you try and tell it that, gpt4 flip flops between avoiding fire and touching the price of tiles
It fails because all the literature on pathfinding talks about is the default approach, and cost heuristic functions. That won’t cut it here, you have to touch the meat of the algorithm and no one ever covers that (because that’s just programming, it depends on what you need to do there are infinite ways you could do it, to fit infinite business requirements)
Huh that’s a neat problem. My instinct was to use a (fire, regular) tuple for cost, but then what A* heuristic can you use…
I guess run it once with no cost for regular tiles and remove fire from any tiles it used. Then run with normal tile costs, but block fire tiles. That doesn’t break ties nicely of course and I’m not convinced the first pass has a good A* heuristic either…
It works but you do it twice when you could do it once
But I expect anyone who’s programmed some pathfinding before to, at the minimum, be able to say “run A* twice”. Somehow AIs never understand the prompt well enough
I think the best option is to make sure to have ‘sorted’ the calls to the fire tiles, you can do that by having them in a separate grid or just stash them to a small local array on stack when you encounter them, and investigate those at the end of the loop
If there’s no result that’s been found under the cost limit without the fire at each point of the algorithm, you do do the recursive calls for the fire as well, and you flag your result as “has fire in it” for the caller on top
When getting a result from your several recursive calls, you take the best non-fire result that’s under 15 tiles long, else you take the best result period
Then once you’re back to the top level call, if there was a non-fire path you will get that result, if there wasn’t you will get that instead
I’ve had 100% failure rate on simple requirements that require a simple spin on well known solutions
“Make a pathfinding function for a 2d grid” - fine
“Make a pathfinding function for a 2d grid, but we can only move 15 cells at a time” - fails on lesser models, it keeps clinging to pulling you the same A* as the first one
“Make a pathfinding function for a 2d grid, but we can only move 15 cells at a time, also, some cells are on fire and must be avoided if possible, but if there is no other path possible then you’re allowed to use fire cells as fallback” - Never works
There for that last one, none of the models give a solution that fits the very simple requirement. It will either always avoid fire or give fire a higher cost, which is not at all a fitting solution
High costs means if you’ve got a path that’s 15 tiles long without fire, but way shorter with fire, then sure, some fire is fine! And if you could walk 15 tiles and go to your destination but need to walk on 1 fire, then it will count that as 15-something and that’s too long.
Except no, that’s not what you asked.
If you try and tell it that, gpt4 flip flops between avoiding fire and touching the price of tiles
It fails because all the literature on pathfinding talks about is the default approach, and cost heuristic functions. That won’t cut it here, you have to touch the meat of the algorithm and no one ever covers that (because that’s just programming, it depends on what you need to do there are infinite ways you could do it, to fit infinite business requirements)
Huh that’s a neat problem. My instinct was to use a (fire, regular) tuple for cost, but then what A* heuristic can you use…
I guess run it once with no cost for regular tiles and remove fire from any tiles it used. Then run with normal tile costs, but block fire tiles. That doesn’t break ties nicely of course and I’m not convinced the first pass has a good A* heuristic either…
It works but you do it twice when you could do it once
But I expect anyone who’s programmed some pathfinding before to, at the minimum, be able to say “run A* twice”. Somehow AIs never understand the prompt well enough
I think the best option is to make sure to have ‘sorted’ the calls to the fire tiles, you can do that by having them in a separate grid or just stash them to a small local array on stack when you encounter them, and investigate those at the end of the loop
If there’s no result that’s been found under the cost limit without the fire at each point of the algorithm, you do do the recursive calls for the fire as well, and you flag your result as “has fire in it” for the caller on top
When getting a result from your several recursive calls, you take the best non-fire result that’s under 15 tiles long, else you take the best result period
Then once you’re back to the top level call, if there was a non-fire path you will get that result, if there wasn’t you will get that instead
Undeniably faster but doesn’t change the big O of course. I wonder how it would benchmark.