ECE-1021

HOMEWORK #6

(Last Mod: 27 November 2010 21:38:38 )

ECE-1021 Home


PROGRAM A - The Monty Hall Problem

Programming Problem #5.20 (p226).

MODIFICATION: User controlled "Verbosity Level"

Many programs permit the user to control how much output is generated - or how verbose the program is. When you are developing your code and debugging it, it is generally very handy to have detailed output. But such output can greatly slow down a program when you are trying to run many millions or even billions of iterations.

Write your program so that the user can decide how game-by-game results are to be displayed by asking them for a "Verbosity Level" as follows:

Level 0 - Don't print out anything during the simulation loop - only before and after the entire simulation is run.

Level 1 - For each game, print out whether the user won or lost.

Level 2 - For each game, print out Level 1 + whether the player stayed or switched (useful for Strategy 2).

Level 3 - Level 1 & 2 info plus cumulative totals (games played, games switched and won, games stayed and won).

Level 4 - Level 1, 2, & 3 info plus cumulative statistics (% won when switched, %won when stayed).

You should find the above easy to implement and very useful in your debugging.

To be turned in with source code:

In the comments of your source code, report your results on whether a player should stay with their initial choice, switch to the other door once Monty opens a non-winning door, or whether it makes a difference. Support your results with an estimate of the probability of winning for each of the three cases based on the output of your program.

Run simulations using each of the above verbosity levels and report (in the comments of the source code) how many simulations per minute you can perform at each level (on the same computer!). To get that value, you might want to write some "wrapper code" that calls the rest of your program in a loop (with a different verbosity level on each pass) and uses the timer functions (in time.h) to measure how long it took to execute the simulation. An alternative is to simply run a large enough number of simulations that it takes at least a few minutes to perform them and sit there with a watch and time how long it takes.

The results might surprise you.

PROGRAM B - Mancala Engine

Your final course project will involve writing a function that, given a copy of the game board, returns a move for the game Mancala. The first step in such a process is to make sure that you know how to play Mancala. For this assignment, you are simply to write a program that let's two players play Mancala. To do this, you need to be able to display the game board in some reasonable way. Since this is not a computer graphics course, you can be quite crude in how you do this. Having a new board scroll onto the screen and the old board scroll up is acceptable. Using the screen I/O functions found in conio.h is even better.

Notice that you are not being given the rules for Mancala. Part of the assignment is for you to go out and find them. Be aware that there are variations of the game but you should quickly discover that there is a basic set of rules that nearly all descriptions agree on. It is this basic version that we are interested in. Do your best to determine what that basic version is. Document in your pseudocode and source code what source you used to get the rules that you implemented (a comment with a URL is sufficient). After this homework is turned in, the "official" rules for the version that your Course Project program has to play will be posted.