For your final project, you will write one of the four programs described below. You will work alone for this project. This does not mean that you shouldn't talk with each other and lab assistants about your project. It does mean that the bulk of your code should be your own, and that any assistance you receive from others should be acknowledged in the comments and documentation accompanying your code.

I: Poker Hand Probabilities

To do this, your program will generate a large number (many millions) of poker hands, and count the number of royal flushes, flushes, straights, full houses, etc. included among those hands. This means that you will need to figure out how to generate a random poker hand, and then how to determine what type of hand it is.

Your program should report probabilities for each of the following types of hands. The term "rank" refers to the card's numerical or letter value.

• Royal Flush: A, K, Q, J, 10, all the same suit.
• Straight Flush: five cards in a row (Aces are high), all of the same suit, but not including Royal Flushes.
• Four of a kind: any four cards with the same rank, plus any fifth card.
• Full House: three of the cards of the same rank, and two cards of the same rank. That is, three of a kind and a pair in the same hand.
• Flush: any five cards of the same suit.
• Straight: five cards in a row (not all of the same suit, since that would be a straight flush).
• Three of a kind: three cards of the same rank, plus two other unmatched cards.
• Two pair: two cards of any one rank, two cards of any other rank, plus one unmatched card.
• One pair: two cards of the same rank, plus three unmatched card.
• Other: any hand that doesn't fall into one of the above categories.

The sorting program I demonstrated in class contains a function called "Shuffle" that you might be able to adapt for your poker hand generation.

II: Moveable Movies

There's a catch, though. Your code must be organized so that the movie can be shown in a frame of any size or location. In particular, your code should include a function described as follows:

	//
	//	DrawFrame
	//
	//	Draws the Nth frame of the movie inside the rectangle
	//	the coordinates of whose top, bottom, and sides are
	//	given by the parameters top, right, bottom, and left.
	//	Note that no drawing is done outside this rectangle,
	//	and that no assumptions are made about the width, height,
	//	or ratio of width to height of the rectangle.
	//	
	
	void DrawFrame( int window, int N, int left, int bottom, int right, int top );

There are lots of cute tricks you can play with your movie if you organize the code in this way. For example, you could show the movie in two locations on the screen simultaneously by doing something like this:

	for( int i=0; i < nFrames; i++ )
	{
		DrawFrame( window, i, 0, 0, 200, 200 );
		DrawFrame( window, i, 300, 300, 500, 500 );
	}

Or you might show all the frames simultaneously in one window, lined up in a grid so you could compare all the frames at the same time. Or you could draw a fancy border, and show the movie inside it.

You need not do any of these things with your code, but you should definitely test it in rectangles of various shapes and positions.

NOTE: DrawFrame should not call g2_open_X11(). In fact, your main program should call g2_open_X11() once, after which g2_open_X11() should never be called again.

III: Bagels

The Guesser makes a 3-digit guess. The Responder compares the guess to the actual mystery number, and responds to the guess by some combination of the words "Pico," "Fermi," and "Bagels." The Guesser keeps guessing until the guess is the mystery number. Here are the response rules:

• If the guess has no digits in common with the mystery number, the answer is "Bagels" or "B."
• If the guess has a digit in common with the mystery number, and the common digit is in the same position in both numbers, the responder says "Fermi" or "F."
• If the guess has a digit in common with the mystery number, but the common digit is not in the same position in both numbers, the responder says "Pico" or "P".

For example, suppose the mystery number is 395. Here are a few guesses and responses:

    246    B
	037    P
    105    F
	309    PF
	etc.

Note that if there are Picos and Fermis in the same response, all the Picos should be reported first. That is, you'd never say "PFP," thus suggesting that maybe the middle digit of the guess was the one in the correct position. Instead, you'd say "PPF," regardless of which digit was the Fermi, and which two were the Picos.

If you want more clarification of the rules of Bagels, let me know.

For this project, you should write a program that will play Bagels with you, both as the Guesser and the Responder. Having the computer act as Responder is fairly straight-forward. Having it act as Guesser is trickier, but fun.

IV: Boggle

For this project, you will write a program that generates a random Boggle board, prints it out, and then prints a list of all the words contained in the printed board using the Boggle rules. You may use the file /Accounts/courses/cs117/ondich/words.txt as the authority on what words are legal.

This problem is easy to state, but not so easy to solve. Good luck.

V: Monte Carlo Integration

Suppose you want to approximate the area under the graph of a function. You may have seen techniques like the trapezoidal rule or Simpson's rule, but there's another technique called "Monte Carlo Integration." Take, for example, the graph of f(x) = x^2 between x=0 and x=2. The graph fits inside the rectangle R = [0,2]x[0,4]. Now suppose you generate a few thousand random points in R. If you compute

# of points under the graph of f
___________________________________

total # of points 

and then multiply this ratio times 8 (the area of R), you'll get an approximation of the area under the graph of f.

For this project, write a program that will compute Monte Carlo approximations of integrals. Your program should present the user with a menu of three or four functions to choose from, and should ask the user to specify the rectangle R (your program does not have to figure out the y interval from a given x interval--that's a hard problem). The user should also be able to choose how many random points your program will generate. Once the user has ordered up an approximation, your program should do two things:

• Open a graphics window, draw the graph of the function, and draw the random points, and
• Print to cout the number of points generated, the number of points falling below the graph, the area of R, and the resulting approximation of the area beneath the graph of the function.

If this project strikes your fancy, then you'll definitely want to use sqrt(4-x^2) as one of your functions.

What to Hand In, When, and How?

• By 5:00 PM, Wednesday, March 8, send me the following via e-mail at jondich@carleton.edu:
  
  
  1. An explanation of which project you plan to do.
  2. Declarations of any major classes your program will use (if any), and prototypes of the major functions in your program. The functional prototypes should include comments explaining what the functions will do.
  3. A pseudo-code version of your main program, with comments.
  4. A brief plan of attack--the order in which you plan to implement your project's features, etc.
  
  
  The more design detail your provide in this e-mail, the better feedback I'll be able to give you. You can send me this e-mail any time before the 17th, and I'll reply by e-mail within 24 hours.
  
  
• By 5:00 PM, Wednesday, March 15, submit the following via HSP:
  
  
  1. All your source files, both .h and .cpp, as appropriate.
  2. A file named finalReadMe.txt, which should include a list of the source files in your project, a description of what your program does, and a description of the status of your program (what works, what doesn't, lingering bugs, etc.).
  
  
  

Grading Criteria

• Does your program compile? I can't test it (and thus can't grade it) if it doesn't compile. Note that many people add their comments only after they have completed their coding. This is a very bad idea from the software design point of view, but it is also a great way to accidentally introduce syntax errors. Always compile and run your program immediately before submitting it.
• Does it work? Correctness is the most important thing, though by no means the only thing. Your program should work. If it doesn't do exactly what it was intended to do, you should provide a discussion of your program's limitations in your documentation.
• Is your program well organized? Well-designed function interfaces, good use of classes where appropriate, and a main program that reads like an outline of the program as a whole contribute to readable, debuggable, and maintainable programs.
• Is your program well documented? Your code is a piece of writing directed to two audiences--compilers and human readers. You need to make the code readable to both audiences, and clear commenting is an essential part of what you do for your human readers.
• Is your program written with good style? Descriptive variable/function/parameter names, consistent indentation and placement of braces, and appropriate comments are the fundamentals of good coding style.
• Sometimes, efficiency is relevant. For example, a bad search algorithm with a big dictionary can lead to unreasonably long run times for a spell-checker.
• If everything above is done well, an ambitious program may get a better grade than a less ambitious one. For example, a spell-checker that can handle an arbitrarily large dictionary is more impressive than one that can handle only 200-word dictionaries. On the other hand, a 200-word spell-checker that is works correctly and is well organized, designed, and documented is much better than a buggy, messy, poorly commented spell-checker that can use a big dictionary.

That's all

Start early, stay in touch, and have fun.