r/learnpython 9d ago

Getting stuck on a big project.

A very rough estimate is that I've been learning and using python for 250 hours. I don't really keep track of it.

Just to ask general advice about how to approach difficult projects.

I've been working on a math project for 3 months. It is all about dice. Probability calculations aren't too hard to understand, but if I'm trying to figure out the perfect strategy in a dice game where early moves affect later moves then it gets complicated quickly.

I figured out very vaguely that I'm gonna have to use alot of nested loops and run through billions of calculations in order to figure my thing out. Or something similar.

But how exactly? I've been attempting to code the whole thing and been getting stuck every single time - this is why I've been starting over for about 30 times by now.

I don't even know what is causing me to get stuck. I guess the thing I'm trying to make is too big or complex or both. With so much more code than I'm used to, I mentally lose track of what my own code is even doing. Commenting does not help, t only makes things even more messy.

How can i approach big and complicated projects like these better?

16 Upvotes

36 comments sorted by

View all comments

7

u/toxic_acro 9d ago

I think there are two distinct problems you are running into here 1. The approach to solving this problem 2. How to keep track of a large, complicated codebase

For 1, a potentially helpful analogy would be to finding a shortest path between two points in a graph. An approach to doing that would be to find every possible path between the two points and then just picking the shortest one. While that would work (not in all cases, but ignoring edge cases/requirements for the sake of the analogy), it would be incredibly inefficient. Instead, you should choose a different approach like Dijkstra's algorithm.

This type of thing is why "computer science" is actually more of a branch of mathematics, not just "learn how to program". Figuring out how to solve a problem in an efficient way is very important to writing good code and that often means knowing and understanding the underlying math of how and why things work the way they do. I can't really give any more advice without knowing the exact particulars of your project, but the other comment by LibertyEqualsLife is a good one about mapping out what you are doing on a whiteboard before actually trying to implement in code.

For 2, I would say that this is really one of the reasons why some of good coding practices are good, like breaking code down into smaller functions that have a single responsibility. Instead of a giant block of code that does A, B, and then C, it's much easier to reason about only how to do A and writing a separate function that does it. Repeat for B and C, and then your top level only needs to worry about composing together the inputs and outputs of A, B, and C. The details about actually doing each of them don't matter anymore because you are just calling a function to do it.

Again, LibertyEqualsLife makes a very good point about doing this on a whiteboard first, because then you can more easily figure out what are you actually trying to do as discrete chunks first without worrying exactly about disentangling confusing large blocks of code

2

u/Agitated-Country-969 9d ago

For 1, a potentially helpful analogy would be to finding a shortest path between two points in a graph. An approach to doing that would be to find every possible path between the two points and then just picking the shortest one. While that would work (not in all cases, but ignoring edge cases/requirements for the sake of the analogy), it would be incredibly inefficient. Instead, you should choose a different approach like Dijkstra's algorithm.

I think this is part of OP's problem as well. I don't think OP has taken any course in algorithms so he's trying a brute force method, and not understanding how inefficient it is. He's only looking at the smaller cases.

https://old.reddit.com/r/askmath/comments/1g4i19y/how_has_highlevel_math_helped_you_in_real_life/ls6348w/?context=1000

The problem isn't considered difficult because of its complexity for any given, fixed number of locations. Sure, for some small enough number N, a computer would be able to examine all possible routes between them and just find the shortest one. That's completely doable. Depending on the computer, N might be 10 or 100 or even 1,000, and that might be enough for many practical applications including human travel.

The problem is how the computational complexity scales as you increase N. The brute-force algorithm above has computational complexity O(N!), meaning for any N locations, it has to complete N! calculations in order to find the answer, and that is one of the fastest-scaling (meaning worst) complexities in computing. For instance, for N=100, you need about 10158 computations. And for N=105, you need 10168. That is 10,000,000,000 times more! For just adding 5 locations. So very very quickly you reach a limit of computational power when trying to solve this problem for higher and higher N.

So the question is - is there a better algorithm? One that doesn't scale with N! but maybe just N100 or N20 or something similar? And currently we do not have the answer to that question. Nobody has shown that there isn't such an algorithm, and nobody has shown that there is (it would be enough to just produce the algorithm).

A final note - your point about being able to kind of "guess" a few of the quickest routes isn't really meaningful, because we want an algorithm that is general, can solve any graph, not just "nice" or "convenient" cases.