I enjoyed this style of problem solving, but it took me a while to figure
out the small straight. I kept thinking that I had it but then I realized
with testing and playing the game that I had forgotten about if the die
had duplicates. Originally 1,1,2,3,4 was not detecting a straight. Then
I thought checking in reverse would help this, but I forgot about
duplicates in the middle (1,2,3,3,4). Ultimately I had to add some code
to remove any duplicates from the list and then it finally worked.
I did find this problem solving to be easier to code once I found the
problem, but sometimes the problem (like with the example above) was not
always apparent. I spent more time thinking about how to solve the problem
in this topic compared to other topics, but less time debugging the actual
code than in previous units. I think I am becoming more familiar with the
coding and am starting to be able to use it to solve new problems.
When writing docstrings, I was trying to decipher what the code was for,
rather than trying to figure out how to solve a problem. It involved some
backward thinking compared to writing code. I found it a bit easier than
writing code (although a lot of the methods referred to each other,
which made it a challenge sometimes).
I think I will include docstrings in the futre with more complex code, so
after writing a block of code, I don't forget what the code was for when
I come back to it later. I think it will be useful in the Games Project.
A class could be used to create an object, such as a molecule in
chemistry. In the class definition, would be functions that could
describe how general molecules behave, look, etc. and then when the
class is called later, certain attributes such as the type of molecule
could be defined. If I am thinking about a class correctly, it could be
used to describe the behavior of a molecule for simulation, but then the
actual individual characteristics of the molecule could be called later.
Chris Mekelburg
cmekelburg