Project 1

Due: 2359 on Sunday, 20 Sep 2020

Introduction

Project 1 is the completion of Lab02. Part 1 requires collaboration between partners to achieve a correct, well tested, and working Financial Simulation program. Part 2 and Part 3 are not collaborative efforts and must be the work of each individual student. These additional instructions should help clarify turn-in requirements.

Part 1: Complete Lab02 (60 Points)

Working with 1 other partner, complete the financial simulator as described in Lab02. If you complete part 1 only, then submit the following:

  1. expenses.cpp & income.cpp.
  2. The image execute0.png.
  3. The images gnuplot0.png and gnuplot1.png.

In a terminal window from your lab02 folder, use the following command to submit your solution: 
~/bin/submit -c=SI221 -p=Project01 expenses.cpp income.cpp execute0.png gnuplot0.png gnuplot1.png

Part 2: Leveraging Modularity (20 Points)

Setup

Assuming that you have followed the naming conventions in the lab assignments to date. In a terminal window run the following: 

cd ~/si221
mkdir projects
mkdir projects/project01
cp labs/lab02/* projects/project01

Follow the GitLab instructions and create a new project using the existing folder that you just put the files into.

Continuing...

Hopefully you see how modular programming helped make a big program managable and helped us distribute the work of programming amongst multiple people in a coherent fashion. However, there's another advantage as well: modifying and improving our program is easier because of our modular approach! Suppose you want to modify the simulation so that ENS Door receives $300 (tax free) per month in unemployment benefits when he doesn't have a job. Is there any question about what has to be changed where? Go ahead and make the change.

Adding on is easier if we keep with this modular approach as well. Suppose ENS Door, a hopeless optimist, buys lottery tickets now and then, and he wants that modelled in the simulation. The lottery takes place at the end of each month, and has a $10,000 payoff. 50% of the time someone wins, but when someone doesn't, the $10,000 pot is carried over into the next drawing so that the pot for next month is $20,000, etc. Tickets are $10 a piece, and each ticket has a 1 in 2,000 chance of winning. (You may assume that if he wins he never shares with anyone but himself!) You can decide for yourselves when (i.e. which months) ENS Door decides to buy tickets, and how many he buys. In adding this new module,you have to define the interface. Be sure to define the interface thoroughly first, in terms of what you'll need in the driver program, and put that in a header file. Only then do you sit down and write the definition!

You will likely find the modulus (%) and rand() useful tools for implementing the lottery module.

Allow the user (via the command line) to make the following choices for frequency of lottery play:

  1. Every month
  2. Every other month
  3. Twice a year
  4. Once a year
  5. Never
  6. Based upon the value of the pot

The user must also specify how many tickets to purchase (via the command line) when playing the lottery.
The function int atoi(char*) returns the integer equivalent of a c-style string.
Feel free to implement more sophisticated strategies (changes tickets bought based upon ...)

Your program should be able to handle commands like:

Take a screenshot of your program running on the above commands. Name the image execute1.png.

Submission requirements include everything from Part 1 and your lottery.cpp and lottery.h files and the image execute1.png.

In a terminal window from your project01 folder, use the following command to submit your solution: 
~/bin/submit -c=SI221 -p=Project01 driver.cpp expenses.cpp income.cpp lottery.cpp lottery.h execute0.png execute1.png gnuplot0.png gnuplot1.png

Part 3: Finishing it all off: Why simulate? (20 Points)

Ultimately you simulate to determine a course of action. So the question we want to answer is this, given ENS Door's financial situation, what does buying lottery tickets do for him? Is it a good idea? How many should he buy? When? One simulation isn't a good way of figuring this out, however. You run it once and he's utterly bankrupt. You run it again, and he's fabulously wealthy. Which run do you trust? What you'd like to do is run the simulation over and over again - perhaps 1,000 times. Then you'd like the minimum, maximum, average and median ending balances of the 1,000 simulations. That'd give you some data to evaluate your lottery ticket strategy. Do it, and come up with what you think is the best strategy, and back it up with stats!

Provide a lottery ticket purchase plan recommendation based on simulations as described above. Back your recommendations for playing the lottery with data from simulations.

Submission requirements are your lottery analysis, recommendations, and supporting data.

Your analysis should compare the average final balance when not playing the lottery versus your best strategy. Explain why you think its good.

Put your answer to Part 3 in a file named part3.txt. Be sure to control the line breaks and check that this file displays well when codeprint is run on it. You are welcome to submit additional files to support your answer, if you so desire; just ensure that they are appropriately named, and modify the below command line appropriately.

In a terminal window from your project01 folder, use the following command to submit your solution: 
~/bin/submit -c=SI221 -p=Project01 driver.cpp expenses.cpp income.cpp lottery.cpp lottery.h execute0.png execute1.png gnuplot0.png gnuplot1.png part3.txt

Extra Credit (up to +10 Points)

Five extra points to whoever comes up with a simulation strategy that results in an average final balance > 11000.
Ten extra points to whoever comes up with a simulation strategy that results in an average final balance > 14000!