Executive Summary

This programming project has you implementing a financial simulation. In this simulation, you have an account, daily expenses that are withdrawn from the account, bi-weekly paychecks, and interest that is compounded daily, but only withdrawn from or deposited in the account every 30 days. Daily expenses are read-in from files that provide data generated by spending models. We provide several examples, e.g. c300.txt, n70.txt, n500.txt, x100.txt, and x500.txt. Note: these files are only a few examples, your programs must work for any properly formatted files. The program's output includes ending balance, ending interest accrued, and average end-or-day balance.
Honor: The course policy and the instructions it references, most pertinently COMPSCIDEPTINST 1531.1C, spell out what kinds of assistance are permissible for programming projects. The instructor can give explicit permission for things that would otherwise not be allowed. For this project, you have explicit permission
  1. to get help from other current IC210 instructors as well as your own and from current IC210 MGSP leaders (any assistance must be documented though), and
  2. to use general purpose C++ resources online (though such use must be documented). Resources that might specifically address this project, say looking through code of programs that do interest calculations, are not allowed.
Put the instructions referenced in the course policy and the explicit permissions above, and what you get is summarized as:

Part 1 [Up to 30pts] - Name your source code file part1.cpp

A Part 1 solution is a program that reads in a command of the form run n filename and prints out the ending balance and average end-of-day balance after simulating n weeks of financial transactions, the specifics of which are detailed below. The filename value is actually ignored in this part, but will be needed in subsequent parts. Here are the rules of this very simple simulation:
  1. The simulation's "paycheck" has default value paycheck = 550.00. The simulation's "initial balance" has default value initibal = 700.00. Though not relevant to Part 1, there are two more parameters with default values. The simulation's "savings rate" has default value saverate = 4.0, and its "loan rate" has default value loanrate = 14.0. In subsequent steps, the user will have the ability to to override these default values.
  2. The first day of the simulation is Sunday, and the account balance starts off with initial balance initibal.
  3. Every other Friday paycheck dollars should be deposited into the account at the beginning of the day. This means that the first Friday of the simulation, nothing will go into the account, but the second Friday there will be a deposit. The Friday after that, nothing goes into the account. The Friday after that there will be a deposit, and so on.
If the user does not enter a command with the proper format run n filename, the program should print the error message Expected : run N file and exit returning 1 rather than zero. Note: at any point in main, return k; exits the program with return value k, even if there are more statements afterwards.
~/$ ./part1
go do 10 
Expected : run N file
~/$ echo $?
1
Note: in the terminal, the command echo $? prints out the "return" value of the previous command/program.
~/$ ./part1
run 1 foo.txt
Ending balance = 700
Average end-of-day balance = 700
~/$ echo $?
0
Note: In this case we only simulate one week, so we don't get a paycheck. 700 is just the initial balance.
~/$ ./part1
run 2 foo.txt
Ending balance = 1250
Average end-of-day balance = 778.571
~/$ echo $?
0
Note: In this case we simulate two weeks, so for the first 12 days we have $700, but for the last two we have $1250 (since we got paid). The average is thus (700 + 700 + 700 + 700 + 700 + 700 + 700 + 700 + 700 + 700 + 700 + 700 + 1250 + 1250)/14 = 778.571.
~/$ ./part1
run 52 foo.txt
Ending balance = 15000
Average end-of-day balance = 7653.57
~/$ echo $?
0
Note: Look at this detailed run on a medium sized input, that shows the beginning and ending balances for each day. This can help in debugging!

Important note: This is a simulation, i.e. the program mimics the actions of a bank. So if you don't have a loop for which one iteration through the loop body models one day in the bank's world, you're going about this the wrong way!

Part 2 [Up to 60pts] - Name your source code file part2.cpp

A Part 2 solution should do all Part 1 did plus it should add to the simulation daily withdrawals from the account defined by the "expenses file" named by the user. Withdrawls happen during the day, i.e. the "end-of-day balance" is the balance after that day's withdrawl (and deposit, if it's a payday) has taken place. You may assume that the expenses file is properly formatted according to the following template
N = x
num1
num2
...
numx
... i.e. the first line tells you how many numbers are in the file, and the rest of the file is simply that many numbers, one per line. The first day of your simulation, the amount of the withdrawal is the first number in the file; the second day the amount is the second number in the file, and so on.
  1. If the file named in the "run" command doesn't exist, you must print out the message File "name" not found!, where name should be replaced with the actual name input by the user. Then the program should return 2 (rather than zero).
  2. If there aren't enough days in the given file to cover the requested period of the simulation, you must print out the error message Insufficient values in "name", where name should be replaced with the actual name input by the user. Then the program should return 3 (rather than zero).
~/$ ./part2
run 52 sadf
File "sadf" not found!
~/$ echo $?
2
~/$ ./part2
run 52 n70.txt
Insufficient values in "n70.txt"
~/$ echo $?
3
~/$ ./part2
run 52 n500.txt
Ending balance = -1684.5
Average end-of-day balance = -601.084
~/$ echo $?
0
Note: Look at this detailed "part 2" run on a medium sized input, that shows the beginning and ending balances for each day. This can help in debugging!

Part 3 [Up to 85pts] - Name your source code file part3.cpp

A Part 3 solution should do everything a Part 2 solution does, but additionally it should allow the user to override the default values for the parameters paycheck, initibal, saverate and loanrate. Specifically:
  1. Prior to giving the "run" command, the user can enter commands of the form parametername = num, entering as many or as few as the user likes, and in any order.
  2. As soon as the "run" command is given, the values of the four parameters initibal, paycheck, saverate, loanrate and are printed out in that order (as shown below); then the simulation starts.
  3. If the user enters a command starting with anything other than run, paycheck, initibal, saverate or loanrate, the program prints out the error message Unknown command "command", where command should be replaced with the actual command input by the user. Then the program should return 4 (rather than zero).
~/$ ./part3
asdf = 10
Unknown command "asdf"
~/$ echo $?
4
~/$ ./part3
initibal = 300.50
loanrate = 7.25
run 10 x500.txt
initibal = 300.5
paycheck = 550
saverate = 4
loanrate = 7.25
Ending balance = 337.25
Average end-of-day balance = 102.557
~/$ echo $?
0
~/$ ./part3
loanrate = 7.25
initibal = 300.50
paycheck = 500.00
run 10 x500.txt
initibal = 300.5
paycheck = 500
saverate = 4
loanrate = 7.25
Ending balance = 87.25
Average end-of-day balance = -4.58571
~/$ echo $?
0

Part 4 [Up to 100pts] - Name your source code file part4.cpp

A Part 4 solution should do everything that Parts 1, 2 and 3 did, but will also incorporate interest into the simulation. The account will be set up so that interest is compounded daily, which for our purposes means that interest will be calculated at the end of each day (i.e. after paychecks are deposited and expenses are withdrawn) using rate/365 as the interest rate. However, the rate used depends on whether you have a positive or negative balance in the account. This bank allows a negative balance, but only at a pretty high interest rate. So, for example, if the rates are saverate = 2% and loanrate = 14%, then when the balance is $85.00 the interest for the day would be
interest = 85 * 0.02 / 365
but when the balance is $-85.00 the interest for the day would be
interest = -85 * 0.14 / 365
Note that your interest is negative when your account is in the negative indicating that you'll lose money, and positive when your account is in the positive. That means when you owe money, you'll owe even more money. Although interest is compounded daily, it is only added to your account every 30 days. That means interest accrues (or builds up) in its own little side account until 30 days have been completed. Then at the very beginning of the 31st day, the interest is added or deducted from your account. Note that at the end of the 31st day, the first bit of the next installment of interest is accrued. Now your program should output the current amount of accrued interest (i.e. not-yet-deposited) along with the ending balance and daily average balance.
~/$ ./part4
paycheck = 600
loanrate = 17.5
saverate = 4.5
run 40 n500.txt
initibal = 700
paycheck = 600
saverate = 4.5
loanrate = 17.5
Ending interest = -2.0123
Ending balance = -181.558
Average end-of-day balance = 177.145
~/$ ./part4
saverate = 4.75   
loanrate = 17.5
paycheck = 615.50
run 40 n500.txt
initibal = 700
paycheck = 615.5
saverate = 4.75
loanrate = 17.5
Ending interest = -0.666627
Ending balance = 137.546
Average end-of-day balance = 329.122
~/$ ./part4
saverate = 2.25
initibal = 1100.00
paycheck = 695.50
run 60 x500.txt
initibal = 1100
paycheck = 695.5
saverate = 2.25
loanrate = 14
Ending interest = 6.27242
Ending balance = 3635.4
Average end-of-day balance = 2237.23
Note: to help in debugging, we are providing one detailed run and another, longer detailed run of the part 4 solution.


When to submit

For IC210, something is considered turned in by "Close of Business" of day X provided that it is in when your instructor comes on on the following day. So, for example, if Project 1 is due on Monday, and I walk in Tuesday morning at 0730 and find a project that's been slid under my door, I treat it as having met that "close of business Monday" deadline — even it was in fact slid under that door at 0729 and the paper is still warm from the printer.
Part 1 of Project 1 must be submitted electronically, and pass all Part 1 tests, by 1530 on Tuesday, September 20th. There is no paper submission at that point. You will submit with:
~/bin/submit -c=IC210 -p=proj01 part1.cpp

The full Project 1 submission is due by COB on Monday, September 26th, according to the course's particular definition of "COB" (see box to the right). Late projects incur a penalty of 3N points, where N is the number of days late. So, a project that is not turned in by COB Monday, September 26th, but which is turned in by COB Tuesday receives a 3 point penalty. A project that is not turned in by COB Tuesday, but which is turned in by COB Wednesday receives a 9 point penalty. And so on. You will submit with:

~/bin/submit -c=IC210 -p=proj01 part1.cpp part2.cpp part3.cpp part4.cpp

What to submit

You will submit the furthest properly functioning solution. So, if your Part 4 solution works, submit the Part 4 solution. If you don't have a properly functioning Part 4 solution, but your Part 3 solution works fine, submit a Part 3 solution. And so on. Note that what you submit must work, and absolutely must compile! What gets submitted is:
  1. Your source code (i.e the .cpp file). You will submit a printout of this (use codeprint) and an electronic copy (how to do the electronic submission will be explained later).
  2. A completed copy of this coversheet on paper.

How to submit

The paper portions of your submission should be stapled together and slid under your prof's door. Instructions on electronic submission: go to the directory with the project files and type:
~/bin/submit -c=IC210 -p=proj01 part1.cpp part2.cpp part3.cpp part4.cpp

How projects are graded / how to maximize your points

Things to keep in mind to receive full marks:
  1. Submit all required items (as described above) on time.
  2. Make sure your output matches the example output in all ways. Note: your numbers could conceivably vary from the example outputs, but only by the tiniest amounts (less than a 1000th of a cent).
  3. Make sure your code is well-commented.
  4. Make sure you follow the IC210 Style Guide. This means proper indentation, use of whitespace within lines of code, logical organization of chunks of code,
  5. What you submit must compile. You will only get credit for the furthest Part for which your program produces correct results.
Most important: Look at the the grading sheet.