Programming Class Week 2
2013-Oct-25, Friday 18:29![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dorchadas
Wherein I learn not to blindly trust advice from people who are supposed to be my betters!
So, context. This week, we're writing a program that plays a simple "guess the number" game. Using the GUI library that they wrote for the class, we have to make it pop up a window, provide two buttons that changes the range of the game from 1-100 or 1-1000, and an input field for the player to put in their guesses. Then the program gives the player a set number of guesses--because, for example, any number between 1 and 100 can be found in seven guesses using binary searching--and when the player runs out, the game fails the player, prints out what the number was, and starts over.
It's the last part that was giving me trouble. Following the instructions suggested by one of the instructors, I wrote the main part of the program like so:
The problem I kept running into was that either the game would end after (number of guesses you were supposed to get - 1), or that the player would get the number of guesses they were supposed to, and then the game would ask for one more input, which would end the game no matter what even the player made that guess correctly. Can you see where I went wrong here?
The problem is the order I set up the operations. Since the checking for how many guesses are left comes before the actual processing of the guesses, it means that after the final guess, the only place to go is back to the beginning of the loop and wait for more input. Then it gets that input, realizes that guesses are zero, and quits the game before it processes the guess, so the player gets the correct number of guesses but has to input a last futile guess to correctly end the game.
Originally, I tried moving the decrement to above the if statement, but that doesn't change the order of processes. All it did was meant that the player got one fewer guess than they were supposed to. Only moving the processing of the guess to the end of the function properly kicked the player out after the last guess. At the very beginning, I had put the check as part of a single if statement that also checked the guess for correctness, but that didn't work, and it took me a while to figure out why. The reason is that it's an if statement, not a "perform one or more of the following as may apply" statement, so it had the same problem as my implemenetation above--namely, that it needed an input to realize that the player had no guesses left.
Apparently there's also a while operator, and I could have jammed the whole thing under while guess_count > 0 [blah blah blah] else: print "LOL UR BAD" / new_game(), but we haven't actually covered that and I didn't want to mess with it, though I might go back and screw around with logs to figure out how many guesses the program gives the player instead of hard-coding in the two possibilities--seven guesses for 1-100 and ten for 1-1000.
And I'm sure there are other ways to implement this. One of the things that peer grading the first assignment showed me is that the obviously correct answer that I, of course, used in my personal implementation of the project was not the only possible way to do it. I don't recall where I read it, but I read a quote that said that you can become an adequate programmer working by yourself, and even a good one, but you'll never become a great programmer unless you work on other people's code and have other people work on yours. There aren't any group projects in this class, but grading each other's assignments at least exposes us to the way other people code.
Also, it's the only possible way to do it because the class has thousands of students and nowhere near enough instructors to evaluate everyone's assignments, but the principle still applies.
So, context. This week, we're writing a program that plays a simple "guess the number" game. Using the GUI library that they wrote for the class, we have to make it pop up a window, provide two buttons that changes the range of the game from 1-100 or 1-1000, and an input field for the player to put in their guesses. Then the program gives the player a set number of guesses--because, for example, any number between 1 and 100 can be found in seven guesses using binary searching--and when the player runs out, the game fails the player, prints out what the number was, and starts over.
It's the last part that was giving me trouble. Following the instructions suggested by one of the instructors, I wrote the main part of the program like so:
>>>Call global variables into the function
>>>If statement to check if the player has no guesses left and end the game if that was true.
>>>Decrement the guess counter
>>>Turn the player's input from a string into an integer so it can be compared to the computer's choice.
>>>If statement to do the actual comparing. If the player is wrong, print "higher!" or "lower!" and run through the loop again. If the player is right, tell them they win and start a new game.
The problem I kept running into was that either the game would end after (number of guesses you were supposed to get - 1), or that the player would get the number of guesses they were supposed to, and then the game would ask for one more input, which would end the game no matter what even the player made that guess correctly. Can you see where I went wrong here?
Originally, I tried moving the decrement to above the if statement, but that doesn't change the order of processes. All it did was meant that the player got one fewer guess than they were supposed to. Only moving the processing of the guess to the end of the function properly kicked the player out after the last guess. At the very beginning, I had put the check as part of a single if statement that also checked the guess for correctness, but that didn't work, and it took me a while to figure out why. The reason is that it's an if statement, not a "perform one or more of the following as may apply" statement, so it had the same problem as my implemenetation above--namely, that it needed an input to realize that the player had no guesses left.
Apparently there's also a while operator, and I could have jammed the whole thing under while guess_count > 0 [blah blah blah] else: print "LOL UR BAD" / new_game(), but we haven't actually covered that and I didn't want to mess with it, though I might go back and screw around with logs to figure out how many guesses the program gives the player instead of hard-coding in the two possibilities--seven guesses for 1-100 and ten for 1-1000.
And I'm sure there are other ways to implement this. One of the things that peer grading the first assignment showed me is that the obviously correct answer that I, of course, used in my personal implementation of the project was not the only possible way to do it. I don't recall where I read it, but I read a quote that said that you can become an adequate programmer working by yourself, and even a good one, but you'll never become a great programmer unless you work on other people's code and have other people work on yours. There aren't any group projects in this class, but grading each other's assignments at least exposes us to the way other people code.
Also, it's the only possible way to do it because the class has thousands of students and nowhere near enough instructors to evaluate everyone's assignments, but the principle still applies.
