Lab 01 - Control Structures
For this lab you will design solution to the Monty Hall Problem.
When the mathematical solution is beyond your reach, a good tractable way to approach these types of analytical problems is to write a program to solve it for you. In this case, we can create a simulation that allows us to play the game thousands of times, and record the results for the two strategies – staying with the initial door or switching (we already know that switching is superior).
You will need to design a virtual game by creating a function for each step of the game. The virtual game will be played by running the functions in order in a script (which we will use next week to create a simulation to test strategies in the game).
- One function that sets up the game (three doors, one car, two goats).
- One function that selects a door for your first guess.
- One function that reveals a goat for the host.
- One function that makes your final pick (depending upon if you intend to stay or switch).
- One function that decides if you win the car or not.
The five functions form the basic steps of the virtual game.
For your homework, submit your knitted markdown file with the following:
- Your five functions, each in its own code chunk.
- Below each include another chunk that tests the function using appropriate arguments and input data.
Note that you will need to think carefully about input arguments and return values for each function. Some function do not need arguments.
The first function that creates a new game, for example, does not require any additional information other than a new game is required. It will randomly assign the two goats and one car to the three doors in the game and return the game set-up.
For the final function, however, in order to determine if the player has won we need information about the door they have selected and the game set-up in order to evaluate whether they win the car or the goat.
Here is some code to get you started.
STEP 1 - CREATE A NEW GAME
create_game <- function( )
{
a.game <- sample( x=c("goat","goat","car"), size=3, replace=F )
return( a.game )
} Test of Function:
STEP 2 - CONTESTANT SELECTS A DOOR
The contestant makes their first selection. Write a function to select one door at random.
STEP 3 - HOST OPENS GOAT DOOR
Note to call this function you need information from previous functions.
The host will always open a door with a goat behind it. But it can’t be a door the contestant has already selected. So it must be a door that is not a car and not a current contestant selection.
Note that if the contestant selects the car on the first guess the host can open either door, but if the contestant selects a goat the host only has one option.
STEP 4 - CHANGE DOORS
The contestant is given the option to change from their initial selection to the other door that is still closed. The function will represent the game-playing strategy as the argument stay=TRUE or stay=FALSE.
change_door <- function( stay=T, opened.door, a.pick )
{
# YOUR CODE HERE...
return( final.pick ) # number between 1 and 3
}# test it
opened.door <- open_goat_door( this.game, my.initial.pick )
change_door( stay=T, opened.door=opened.door, a.pick=my.initial.pick )
change_door( stay=F, opened.door=opened.door, a.pick=my.initial.pick )
my.final.pick <- change_door( stay=F, opened.door=opened.door, a.pick=my.initial.pick )
this.game
my.initial.pick
my.final.pick STEP 5 - DETERMINE IF CONTENSTANT HAS WON
determine_winner <- function( final.pick, game )
{
if( ...YOUR CODE HERE... )
{
return( "WIN" )
}
if( ...YOUR CODE HERE... )
{
return( "LOSE" )
}
}# test code
this.game
my.initial.pick
my.final.pick <- changeDoor( stay=T, opened.door=opened.door, a.pick=my.initial.pick )
determine_winner( final.pick=my.final.pick, game=this.game )
my.final.pick <- changeDoor( stay=F, opened.door=opened.door, a.pick=my.initial.pick )
determine_winner( final.pick=my.final.pick, game=this.game )TEST THE GAME
# your game "recipe"
this.game <- create_game()
my.initial.pick <- select_door()
opened.goat.door <- open_goat_door( this.game, my.initial.pick )
# save results for both strategies for the game
my.final.pick.stay <- change_door( stay=T, opened.door=opened.goat.door, a.pick=my.initial.pick )
my.final.pick.switch <- change_door( stay=F, opened.door=opened.goat.door, a.pick=my.initial.pick )
# print game details and if you won
# if you stayed:
paste0( "GAME SETUP" )
this.game
paste0( "My initial selection: ", my.initial.pick )
paste0( "The opened goat door: ", opened.goat.door )
paste0( "My final selection: ", my.final.pick.stay )
paste0( "GAME OUTCOME:" )
determine_winner( final.pick=my.final.pick.stay, game=this.game )
# if you switched:
paste0( "GAME SETUP" )
this.game
paste0( "My initial selection: ", my.initial.pick )
paste0( "The opened goat door: ", opened.goat.door )
paste0( "My final selection: ", my.final.pick.switch )
paste0( "GAME OUTCOME:" )
determine_winner( final.pick=my.final.pick.switch, game=this.game )
Challenge Questions
PART 01:
Let’s change the rules a little to make outcomes more interesting. Create a board with 5 doors and 2 cars. After the contestant makes an initial selection the host will open one car door and one goat door. If the contestand decides to switch they then have to select from the two remaining doors.
How does this new board change the pay-off from the game? Is switching still the best strategy?
PART 02:
We are building functions to play a game in a static world. There are always three doors, one car, and two goats.
What happens if we are in a dynamic world? The game can have three or more doors (in a game with two doors there would be no switching so there is no strategy to study). And we can also have one or more cars up to N-2 (N being the number of doors, there always need to be at least two goats so that the host can open a goat door, even if the contestant selected a goat in the first round).
How would you change the code to model this new world?
Submission Instructions
When you have completed your assignment, knit your RMD file to generate your rendered HTML file. Platforms like BlackBoard and Canvas often disallow you from submitting HTML files when there is embedded computer code, so create a zipped folder with both the RMD and HTML files.
Login to Canvas at http://canvas.asu.edu and navigate to the assignments tab in the course repository. Upload your zipped folder to the appropriate lab submission link.
Remember to:
- name your files according to the convention: Lab-##-LastName.Rmd
- show your solution, include your code.
- do not print excessive output (like a full data set).
- follow appropriate style guidelines (spaces between arguments, etc.).
See Google’s R Style Guide for examples.
Markdown Trouble?
If you are having problems with your RMD file, visit the RMD File Styles and Knitting Tips manual.
Notes on Knitting
Note that when you knit a file, it starts from a blank slate. You might have packages loaded or datasets active on your local machine, so you can run code chunks fine. But when you knit you might get errors that functions cannot be located or datasets don’t exist. Be sure that you have included chunks to load these in your RMD file.
Your RMD file will not knit if you have errors in your code. If you get stuck on a question, just add eval=F to the code chunk and it will be ignored when you knit your file. That way I can give you credit for attempting the question and provide guidance on fixing the problem.
