1
$\begingroup$

The derived class is a Vanilla Option on a Future and I need to specify the expiry of the underlying future which is in general different (later) than the expiry of the Vanilla Option. I have implemented a couple of PricingEngine that derive from VanillaOption::engine and for the moment their respective calculate() methods assume that the expiry of the future coincides with the expiry of the option.

I plan to proceed as follows:

  1. Declare the derived class VanillaOptionFuture as follows: class VanillaOptionFuture : public VanillaOption
  2. Define a new type of argument for this class as follows: class VanillaOptionFuture::arguments : public VanillaOption::arguments and add a new field called futureExpiry_.
  3. Redefine the method setupArguments for class VanillaOptionFuture in order to call the homonymous method of class VanillaOption plus setting the futureExpiry_ field of the arguments class, which will be passed to the constructor of the class.

Question: I would like to keep my pricing engines working for the general case of a VanillaOption with the default behavior futureExpiry_ = arguments_.exercise->lastDate(). I was thinking on leaving the declarations of my pricing engines as they are and just deal with the two cases directly in the calculate() methods by using boost::dynamic_pointer_cast. Do you think this is the right way to proceed? Thanks for any advice.

$\endgroup$
1
$\begingroup$

It's kind of complicated. I'm afraid QuantLib doesn't have a "right" way to do this.

The short answer is that the way you sketched (inheriting from VanillaOptionFuture::engine) should work. You might not even need a dynamic_cast; if you're passing the engine to a VanillaOptionFuture, it will set the futureExpiry data member, whereas if you're passing the engine to a VanillaOption it will ignore it. Inside calculate, you can just check whether futureExpiry is a null Date().

The longer answer is that the class diagram you're building is a bit shaky. You're starting from

class VanillaOptionFuture : public VanillaOption

which lets you avoid duplication of all the code around data members but, in C++ idioms, is saying "a vanilla option on a future is a particular kind of vanilla option". This lets you avoid a lot of code duplication, so let's go with it, but it can take a reader aback a bit if she's thinking that a vanilla option is an asset option. Anyway, as I said, let's go with it.

The relationship between the corresponding engines, and it is going to be tricky. You didn't say how you plan to implement it, but you need a new argument class, so you also need to define a new VanillaOptionFuture::engine class; you can't just reuse VanillaOption::engine, whose argument class is fixed.

Possibility 1: if you inherit VanillaOptionFuture::engine from VanillaOption::engine, you're saying that an engine for a future option is an engine for an option, which in your case looks right—your engine can price both—but it's not guaranteed in general, since a given engine for futures option might rely on futures data which are not available from plain options.

Possibility 2 is to define VanillaOptionFuture::engine as independent of VanillaOption::engine and sidestep the semantic problem. You can also sidestep the semantic problem by going for possibility 1 and simply not thinking about it. :)

In both cases, the compiler won't complain; VanillaOption checks the type of the engine only indirectly, through the type of its arguments class, and that one will be correct since you inherit VanillaOptionFuture::arguments from VanillaOption::arguments.

Both possibilities will work, but the relationships between classes are not very well defined, which might make the code confusing to readers. As I said, though, QuantLib doesn't have a right way to do this, so the way you're proposing looks good to me.

$\endgroup$
  • $\begingroup$ What about a private inheritance? Private inheritance implies VanillaOptionFuture uses VanillaOption. $\endgroup$ – SmallChess Jan 7 '16 at 0:56
  • $\begingroup$ That would cause VanillaOptionFuture to inherit twice from Instrument (once privately through VanillaOption and once publicly because it is an Instrument). It's diamond inheritance, and Instrument has a lot of behavior. Making it work might be more trouble than it's worth. $\endgroup$ – Luigi Ballabio Jan 7 '16 at 9:33
  • $\begingroup$ @LuigiBallabio I followed alternative number 2. Thanks for the help. $\endgroup$ – Giancarlo Giuffra Jan 9 '16 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.