Hi! I downloaded your repository on 26th of April 6:30pm. Here are my thoughts

Testing

-Testausdokumentti is empty! Even though it's a perfect place to explain how do you the test files in /src/tests, or describe what you plan/have tested so far. The visualization is very usable, so even commenting on the fact that you "visually checked" that the programme works is valuable for the document. Also a simple thing to add would be to write:

poetry shell
pytest src

which makes it more obvious what to do. At first I assumed there is no tests because poetry run invoke test didn't work and there was no such task in tasks.py. -The course materials provided a lot of useful testing tools. I can't imagine developing my code without tests, and I run tests almost every time I make a major change to my programme. They are super useful! Definitely check out the course materials on testing, and definitely implement at least some unit tests! Making a coverage-report, lint, and format tasks could also help, feel free to check out my tasks.py file.

Documentation

In Toteutusdokumentti Dijkstra isn't mentioned next to a_star and fringe_search. I understand that Dijkstra is implemented as something like an A search algorithm but without any heuristics. I got that from reading index.py but it made me slightly confused because the way I learnt this way by starting the application and seeing Dijkstra, Fringe search and A start as filters of what I can see in the visualization: And then later finding that detail inside index.py. For me, it's nice when details like those are reflected in the documentation, and not just the README.md page, even if you just mention that Dijkstra runs on the same code as A but without the heuristic.

Naming

height_mapping_function "determines the cost of moving from one cell to another based on their position and height difference", so perhaps it could be simply called cost. Similarly, heuristic_function could simply be heuristic. Other method and function names are intuitive :+1:

Lack of UI

Judging by the code, the outcome, and the pictures in documentation I'm convinced the programme works, but it lacks an interface through which I could change the parameters of the algorithm, and according to the course materials, it's super important! Even a simple CLI interface like this or the would work. The parameters could be as simple as start and end points and the seed. A cli.py is also a perfect way to refactor some of the stuff that otherwise lands in index.py and making it easier to read.

Comments and docstrings

It's nice to see comments in your code like

        # Linked list has a default start node at size ** 2

But on a higher level, it would be nice to know what each function does using docstrings. E.g. in a_star.py I can find both find_path and a_star functions:

def find_path(goal, nodes, size):
....
def a_star(start_cord, goal_cord, grid, heurestic_function=heurestic_function, height_mapping_function=height_mapping_function):

It would be easier to read the code if find_path and a_star had docstrings that explain what each function does and what kind of input they take. After all, it's not obvious at first if a_start returns the shortest path, produces a path, draws the map or if that's the responsibility of find_path.

Positive things

The visualization is very cool :sunglasses: ! Choosing the different option from Dijkstra, Fringe and A Star I can see what paths the algorithms have taken, turn the map around, make a picture and easily get the grasp of what the application does

Toteutusdokumentti contains very important details, like explanations of specific functions. It's nice to see explanations where there might be doubt as to what specific functions do.
It's nice that heuristic_function is factored out of the algorithm, this makes updating the heuristic and the algorithm separate and more convenient
Using Perlin noise and 3d visualization works fast and looks very smart :brain:, congrats!

levitesuo / algoritmit-harjoitusty-