Earlier quoted context omitted.
Pretty much the entire project.
I think so too. Also, what's the point of using git with commit messages like that? https://github.com/Dicklesworthstone/visual_astar_python/com... LoL.
Show HN: Visual A* pathfinding and maze generation in Python
41–48 of 48 posts
Re: Show HN: Visual A* pathfinding and maze generation in Python
#42Earlier quoted context omitted.
No problem. I also don't think you should be worried or disappointed about finding something interesting no matter what its provenance. As long as it's correct/fascinating (and in the case of this project, the animated output itself shows that it's doing something useful/interesting), none of that should really matter ultimately. I'll take a look at your project, sounds cool. As for the temporal logic essay, you're v…
Returning to this conversation I think I misread your previous comment: you are saying you did use an LLM to generate some parts of the code and text in your repository, just not all, or not all in one go, or with only a couple of prompts. Is that correct? >> I also don't think you should be worried or disappointed about finding something interesting no matter what its provenance. I disagree. There are two issues her…
Re: Show HN: Visual A* pathfinding and maze generation in Python
#43I'm wondering if there's someway of abusing the heuristic to produce an absolute monster of a maze; Somehow make it so that the top ~70% of next steps in the queue are never the next step in the solution (I'm too tired right now to come up with any sort of answer, but my guess is that it wouldn't be possible to generate a planar maze that way).
ooh it would be super interesting to 3d print the maze and then watch ants solve it
Really fun to watch.
Re: Show HN: Visual A* pathfinding and maze generation in Python
#44Re: Show HN: Visual A* pathfinding and maze generation in Python
#45Earlier quoted context omitted.
Returning to this conversation I think I misread your previous comment: you are saying you did use an LLM to generate some parts of the code and text in your repository, just not all, or not all in one go, or with only a couple of prompts. Is that correct? >> I also don't think you should be worried or disappointed about finding something interesting no matter what its provenance. I disagree. There are two issues her…
I wouldn't be surprised if the majority of things shared contains some LLM generated code. Everyone I know is using Copilot or some other code assistant and a few even use things like Cursor where the LLM takes the driver's seat. This is not the novel anomaly you make it sound like.
Re: Show HN: Visual A* pathfinding and maze generation in Python
#46I like this..I recently used A* to implement laying out connectors between nodes in a graph. I really like the abstraction of a heuristic function. I was able to add in all sorts of things to make the implementation work the way i want (penalise turns, crossing over lines etc.). This would automatically create "last resort" style solutions and minimise ugliness in the diagram.
The heuristic is the wrong place to adjust solutions, just change the costs on the original problem and adjust the heuristic if necessary. I guess that for your intention, using an inconsistent heuristic that over-estimated costs and resulted in sub-optimal solutions was fine because you wanted sub-optimal solutions in your penalty-free problem, but this was better modeled by a modified problem that either penalized…
Re: Show HN: Visual A* pathfinding and maze generation in Python
#47Earlier quoted context omitted.
The heuristic is the wrong place to adjust solutions, just change the costs on the original problem and adjust the heuristic if necessary. I guess that for your intention, using an inconsistent heuristic that over-estimated costs and resulted in sub-optimal solutions was fine because you wanted sub-optimal solutions in your penalty-free problem, but this was better modeled by a modified problem that either penalized…
That's a good point. I didn't think of like that. I think the "don't allow" cases might be modelled in the heuristic but my initial graph was just all open.
Hacking only the heuristic side will seem to work as intended on short paths, but as the f-value (g+h) naturally starts being dominated by g as the solutions become longer, you'll see that the hints at what not to do embedded in the heuristic will start to seemingly become neglected by A*
Re: Show HN: Visual A* pathfinding and maze generation in Python
#48Earlier quoted context omitted.
That's a good point. I didn't think of like that. I think the "don't allow" cases might be modelled in the heuristic but my initial graph was just all open.
I'm not sure what you mean by the initial graph being just all open, but I'm still convinced that modelling things only in the heuristic is wrong. Here's why it fails eventually, Hacking only the heuristic side will seem to work as intended on short paths, but as the f-value (g+h) naturally starts being dominated by g as the solutions become longer, you'll see that the hints at what not to do embedded in the heuristi…
I see your point. The penalties right now are "big" but only when compared to the values of g at the beginning. As it moves forward, even the big penalties will be swamped by the g and hence, the heuristics will be ignored.
I'm not sure about how else to model this though.