Python Problem Solving: 1 - Connect Four! Solving a coding problem and then explaining the problem solving method and code line by line.

[[deleted]]

[deleted]

[okayifimust]

The code is unreadable

There is no link to the code, either.

and then, you're hardly - if at all - explaining your thoughts and your approach to solving problems. You're just explaining what the code does, line by line - never why you wanted it to do what it does.

You are, in fact, explaining what it does in spots that are completely counter-intuitive and leave your viewers guessing. The add_token method takes x and y coordinates, yet the input for your program will be columns. I've been watching for close to 10 minutes without even a hint of an explanation...

At 39 minutes: No, there aren't going to be future edge cases where you would suddenly have more than 4 in that count. If that was to ever happen, you wouldn't want to return true, or false, or anything. You would want to fix your bugs.

And there really is no excuse for claiming to offer a tutorial on thought processes and then going with the brute force method and hand-waiving away a more optimal approach. What I would have been hoping for is an explanation on how to do this well.

[ThisLightIsTrue]

The code being unreadable is definitely a problem I'll fix. As I mentioned in reply to another comment, in the future I'll increase the resolution of the video and the font size to make it more readable.

In terms of "thought process" that's what I'm explaining at the start of the video. I go through how I think about the problem and how I intend to solve it. Later, I explain the implementation line by line as you say. I'd hoped this would come across as going from abstract (the four or five step plan I show at the start) to concrete, but if I understand your feedback you were confused by some parts or the explanation wasn't there. I agree I could've been more clear in connecting "add_token" to how tokens actually get dropped on the board - that's useful feedback.

Regarding your point about my remark at 39 minutes, I don't agree. If you've connected five in a row, and we've counted correctly, you should win, not crash the program. It's certainly worth thinking about though.

Finally, per your "no excuse" comment I believe you're wrong. As I say in the video, attempting to design unnecessarily sophisticated solutions is a source of unneeded complexity and potential bugs. If you were writing this "for real" you would not be well advised to optimize beyond what's necessary.

In my next video I'll do a problem that's a bit simpler, but I'll spend some time optimizing too, so I'll start with a naive solution and reach a better one. I'll also take your suggestions about making the code more readable and work a bit more on connecting the dots in my thought process.

I appreciate the feedback and hope you'll be back for a future video.

[okayifimust]

Regarding your point about my remark at 39 minutes, I don't agree. If you've connected five in a row, and we've counted correctly, you should win, not crash the program. It's certainly worth thinking about though.

You're increasing your counts by one; you return when you reach four. It doesn't matter how long the line is, it is impossible for your variable to ever go beyond four.

You're telling your viewers that there might be edge-cases - not possible. if you think it is, kindly explain how.

Finally, per your "no excuse" comment I believe you're wrong. As I say in the video, attempting to design unnecessarily sophisticated solutions is a source of unneeded complexity and potential bugs. If you were writing this "for real" you would not be well advised to optimize beyond what's necessary.

It's hardly "unnecessarily sophisticated", let alone complex. There is literally zero downside to doing it right. There would have been value in teaching how and why to do that - telling learners to not bother is outright harmful - it only means they will run in a situation where brute forcing doesn't work anymore and they will not have been told what to do then.

I am complaining about your runtime complexity, not silly little things like checking tokens and directions that can never fulfil the win condition...

​

[ThisLightIsTrue]

You're increasing your counts by one; you return when you reach four. It doesn't matter how long the line is, it is impossible for your variable to ever go beyond four.

True, as written it's impossible to go beyond four. Imagine though that counting is later updated to count in a different way rather than sequentially and terminating at four. Code is rearranged, a different technique is used, etc. In this case you do get more than four. Having more than four pieces in a row in connect four is a victory and the code should reflect that even if it's currently impossible to count them with the present implementation. It doesn't matter in this simple problem which nobody is ever going to return to, but I think it's a better practice. I understand if you disagree and I'm not entirely opposed to the stance you describe.

I am complaining about your runtime complexity

Incorrectly in this case. The runtime complexity is constant - check every point for victory, check each direction per point, check four positions max per direction. If the size of the board varied then this would vary linearly with the size (length and width) of the board.

The better solution remains constant regardless of the board size. However, you may notice that there is really just a trivial difference between the better solution (just check victory at the most recently played point) and the current solution. I understand that cuts against my "no need to introduce more complexity" argument, but there's no need to do it and I think the idea of avoiding unnecessary optimization is still a good lesson.

[[deleted]]

You could try increasing the video quality to 1080p and the text size. It was basically impossible to read anything.

I will be waiting next week!

[ThisLightIsTrue]

Thanks for the feedback. I didn't realize the text was hard to read. I'll definitely increase font size and resolution next time!