Extending QuantLib Option Engines for Options on Futures

# Answer by Luigi Ballabio (score 2, accepted)


# QuantLib: New Instrument derived from VanillaOption + PricingEngine that must work for both VanillaOption and the derived class












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:

- Declare the derived class VanillaOptionFuture as follows: `class VanillaOptionFuture : public VanillaOption`

- Define a new type of argument for this class as follows: `class VanillaOptionFuture::arguments : public VanillaOption::arguments` and add a new field called `futureExpiry_`.

- 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.

## Answer by Luigi Ballabio (score 2, accepted)

https://quant.stackexchange.com/a/22598

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.