ECE-1021
HOMEWORK #6A Solution Notes
(Last Mod: 27 November 2010 21:38:43 )
If you look at the Instructor's Solution source code, you will see that this program was implemented in a highly modular fashion.
Another thing that you should note is that the data that had to be passed back and forth between the functions - especially at the higher levels - was packed into two arrays. The concept that might be new to you is the notion of packing numbers that mean highly different things into the same array. Normally, when we think of an array of something, we think of a group of values that are intrinsically related - for instance the characters in a text string or the height of a rocket at successive time steps. But if we divorce the concept of data type from data interpretation, we see that as long as we can represent each of the pieces of data using the same data type, then there is absolutely no requirement that those pieces of information have anything else in common. The compiler doesn't care. Once we understand this and start exploiting it, we are one step removed from the concept of structures where even the requirement that all of the pieces of data have the same type is removed.
With regards to the game simulation itself, many people have a hard time understanding the difference between simulating the game and invoking the results of an analysis of the game. For instance, many people will ask the user if they plan to switch or stay and, if they say they will switch, then in each game they randomly pick the door the user chose and the door with the car and, if they are the different, declare the person a winner. This is not how the game is played. This is the outcome that an analysis of the game expects to have happen and so the programmer codes a different set of rules that they believe and expect will produce the same outcome.
But what if their beliefs are wrong? This is a fundamentally flawed way of approaching most simulation tasks since the whole idea is for the simulation to reveal the system behavior independent of any analysis - and hence independent of any errors that might be a part of that analysis.
To highlight this, consider that the vast majority of people believe that the odds of winning the Monty Hall game are 50-50 regardless of whether the player stays or switches. This makes intuitive sense and it is even very easy to perform a rigorous analysis of the probability of winning and show this to be true. Having done that, you could write a simulator that asks all the right questions and then generates a two-state random number that determines the final win/loss and now your simulator "proves" your analysis.
Unfortunately, the analysis that most people make only counts the number of possible paths that the game can take - half of which lead to a win and half of which lead to a loss regardless of the stay/switch decision. But in doing the analysis this way an unconscious assumption has been made that each of those paths is equally likely. It turns out that they aren't. The only way to prevent such an error in analysis from affecting the simulation results is to be scrupulous about not using any analysis results in the simulation in the first place. This means that you simulate the system faithfully according to rules that govern the system. You don't take shortcuts.