Units consistency

1. Units consistency • $10,000,000 of a bond means 10000 actual bonds assuming “face” is $1000 (almost always) • 9% coupon, 20 years to maturity • Current price: 134.6722 and yield is: 6% • If price is 134.6722 market value is: $10,000,000 * 1.346722 = $13,467,220 Total position does not incorporate price - just add up the face amounts of each position • If we increase yield by by 100 basis points (1%) price is now: 121.3551 • Our data file has amounts in 000’s so $10,000,000 would be entered as 10,000 (with no comma but it’s easier on the eyes to use commas in example spreadsheets) • Dollar Value of an “01” (DV01) - price diff between starting yield and 1/100th of a percent move of yield, or 1 basis point, (1/100th of above example). Additionally, it is the average of two shifts: the absolute value of the differences resulting from both an up and down move. • “Risk” for us is defined as Amount * DV01/100 and thus stays in thousands since Amount is in thousands. Amount is the same as “position”. Our positions are made up of N trades. • double yield_delta_abs = fabs(bump_amount); • // yield goes up, price goes down • double down_price = PV(base_yield + yield_delta_abs); • double price_delta_down = base_price - down_price; • // yield goes down, price goes up • double up_price = PV(base_yield - yield_delta_abs); • double price_delta_up = up_price - base_price; • dv01 = (price_delta_up + price_delta_down ) / 2.0;

2. Units consistency Cont… • As long as amount is signed, calcs should work out • Long is positive • Short is negative • Example: if dv01 is same (or materially close), then you are perfectly hedged with position A = 1000 and position B = -1000 • Precision • Bond conventions cover how to massage price. Also, govt bonds are quoted in fractions (32nds, 64ths, etc which we haven’t been doing). • Rounding • Truncation • Always calculate everything using doubles and if instructions are to show 3 places of precision then: printf(“number: %.3f\n, number); • We are showing totals in thousands - “000’s” when deriving “risk”, and “position”. We will also show VaR in thousands even though normally shown in millions. • Price and dv01 are always in percent so need to divide by 100 before multiplying to get totals • Refer to example spreadsheet for 2 year OTR treasury

3. Mid-term feedback • I shouldn’t have to change makefiles or touch code • Only edit should be in run.sh to run against another file in a different location • Units should be in thousands throughout • Provide a README file • Use meaningful, descriptive variable names - as opposed to “a”, “b”, “c” • Free memory. Now that you have a server this will matter :) • Identify class member data consistently like: “_price” or “i_price” (defacto’s for C++ programmers) • Use mf TCM() for indentifying bond (not ID - this will be used internally only) • Always use curly braces • Don’t copy objects - pass by const ref or use pointers. Shouldn’t need to. Sometimes safer to disable copy constructors. • Comment the main and include the string “main” in the name of the file • Price and dv01 is a percentage so need to divide by 100 before calculating market value, etc. • Use the run.sh shell script • Timer routines were provided so they would be included. Include in server side now in message parser. • Use indents of 4 spaces or 1 tab and comments in source code • Format output using tabs and newlines • Parameterize by filename but need to check if not passed - don’t bomb out - fail gracefully. • Amounts can be negative (short positions) • Debug io kills performance - #ifdef out before submitting or do a quick compare at runtime on a global variable • Interface classes should not contain state (member variables), add another level in hierarchy • Use interface classes as pointers vs the derived types • Text titles cut/pasted - archaic comments are evil • Unnecessary copying from provided objects (could use pointers) • Only build what you have to - don’t “program to impress your friends” e.g., follow instructions carefully. • Don’t use makefiles for anything other than building code - use shell scripts instead

4. Mid-term Submission • No team got ALL the numbers right • 2 teams took some liberties with the instructions • Which team wrote the fastest code? • Not as valid since accuracy was an issue but top 3 were close • Team 2 & 5 were closest with accuracy and took gold and silver for speed! • Good job Weili/Enzhou • Lin/Ganchao

5. Remainder of Semester: • For next week I will review your code - 10 minutes per team after a review lecture of all the things we have covered and what our app capabilities provide us in the real world… • Credit Risk measurement (LGD) and VaR are ahead • Next week I’ll sit with each team to clarify requirements and check server side numbers. • Server-side with client driver (not full GUI) due Dec 13 • Will grade accuracy and performance before final demo during final week • Final presentations Dec 20 - dazzle me with some cool graphics!

6. Top 3 Execution Times