Hansei time.
I've managed to get some good feedback on my Monty Hall implementation, both on the internet and in the classroom. In particular, my Programming Languages Professor was kind enough to point out that, in my 10^6 example, that most of the computational time was being spent on the generation of the revealed list of gameshows, not the execution. This was aligned with criticisms that I should reconsider making a struct of a struct be the centerpiece of the program... and I agree. After all, this program was written totally just for me understand how on earth the relationship between staying and switching was possible. Therefore I try to produce what felt like the most accurate simulation possible-- being presented a random set of 3 doors with the prize (a Monty), randomly selecting a door (within Choice), the host informing me that another door contains a goat (host-reveal) and then the program picking up whether staying or switching would win the game.
However, now that I understand what the results should be, and how to get there, I can start trimming up the program significantly to be a lot more lean. The first solution I propose is dissolving Monty and Choice, and simply making gameshow a list of 6 items. After all, Monty and Choice are both three values that would function well as a list anyways. We could consider the Choice "part" of the list to be the first half, and then the Monty to be the second half. This would require a lot of diligence in writing functions, but may significantly cut down on time. I'll give it a try over break, and possibly even benchmark the two against each other. : )
No comments:
Post a Comment