1. YTM - Pricing a Zero Coupon

2. Indirection, Polymorphism, Data Abstraction -How to handle a heterogeneous mix? -Coupon-bearing -Zero Coupon -What does data-driven mean? -Pricing function signature -Data-file “schema” -Is-a, Has-a, Uses… -Envelope/letter -Memory management -Collection requirements: -Searching -Totals -Partitioning

3. Deliverables for Oct 18 -Build in support for a “Zero Coupon” Bond -Build a Trading Book collection class to handle a heterogeneous mix of types… -Possible “collectable” abstractions: -Instrument -Calculator -Bond -Criteria for class design: separately testable -Best way to use the SBB_io class data? -Inherit? Contain? Use? (“is-a”, “has-a”, “uses”…) -Load in new a data file to test an expanded portfolio of bonds (coupon-bearing and zero-coupon) -How to discern bond type from external persistent store?

4. Deliverables for Oct 18 continued… -Download new version of data input file -New data items which will have to added in SBB_io class: -Ticker (unique ID that identifies the issuer of that bond) -Amount (this is the total position for that bond, in thousands) -Quality code (the credit rating for that issuer - we will use this later) -You will have to add a convenience mf() for our ndustry standard identifier: “Ticker Coupon Maturity” (just a concatenation of existing fields) -Using trading book collection class to calculate: -Total position -Positive amounts are “long”, negative amounts “short” -For example, if you two positions in a trading book (1 long position of 1MM and 1 short position of 1MM), then you would be “flat” on a notional or “face amount” basis. However if the dv01’s are different, then your risk would not be flat… -Total first order risk ( dv01 * amount )