1. (Analysing Code)

The C++ code in Section 11.4 was not written with maintainability in mind. In fact, it was written in a hurry because the manager wanted to see results for a quick prototype, a perfectly acceptable reason. In this exercise we carry out a forensic investigation as it were to determine the level of flexibility of that code and how it can be adapted to suit new requirements. It would be unwise to use this prototype as the basis for future work.

Answer the following questions:

a) Determine the parts of the code that are hard-wired (hint: for example, the code only caters for call options but we may also like to support put options).

b) Which C++ functionality can you use to make the code more flexible, for example subtype polymorphism and class hierarchies, function objects and lambda functions?

c) Adapt the code so that it can support a barrier option family (there are eight choices):
down-and-out call, down-and-in call, up-and-out call, up-and-in call, down-and-out put, down-and-in put, up-and-out put, up-and-in put. What is the most flexible way to model these without introducing hard-wired conditional logic or code duplication (the infamous copy-and-paste syndrome)?

d) Test the code by comparing the answer obtained for large expiration against the exact solution for a perpetual American call option (see Haug, 2007 for the formula or Section 12.4.3 of the current book).

e) Modify the code so that it can support rebates. Test the accuracy of your results.

f) Consider an American call option with barrier H = 0. How many steps are needed in order to achieve the same accuracy as we get using the Bjerksund and Stensland (2002) or Barone–Adesi–Whaley closed-form approximations, for example? (See Haug, 2007.)