QuantLib: Nuevo instrumento derivado de VanillaOption + PricingEngine que debe funcionar tanto para VanillaOption como para la clase derivada

Question

La clase derivada es una Opción vainilla sobre un futuro y necesito especificar el vencimiento del futuro subyacente, que en general es diferente (posterior) al vencimiento de la opción Vanilla. He implementado un par de PricingEngine que se derivan de VanillaOption::engine y por el momento sus respectivos calculate() Los métodos suponen que el vencimiento del futuro coincide con el vencimiento de la opción.

Pienso proceder de la siguiente manera:

1. Declarar la clase derivada VanillaOptionFuture de la siguiente manera: class VanillaOptionFuture : public VanillaOption
2. Defina un nuevo tipo de argumento para esta clase como sigue: class VanillaOptionFuture::arguments : public VanillaOption::arguments y añadir un nuevo campo llamado futureExpiry_ .
3. Redefinir el método setupArguments para la clase VanillaOptionFuture para llamar al método homónimo de la clase VanillaOption además de establecer el futureExpiry_ de la clase de argumentos, que se pasará al constructor de la clase.

Pregunta: Me gustaría que mis motores de precios funcionaran para el caso general de un VanillaOption con el comportamiento por defecto futureExpiry_ = arguments_.exercise->lastDate() . Estaba pensando en dejar las declaraciones de mis motores de precios tal y como están y tratar los dos casos directamente en el calculate() métodos mediante el uso de boost::dynamic_pointer_cast . ¿Cree que esta es la forma correcta de proceder? Gracias por cualquier consejo.

Answer 1

Es un poco complicado. Me temo que QuantLib no tiene una forma "correcta" de hacerlo.

La respuesta corta es que la forma en que se ha esbozado (heredando de VanillaOptionFuture::engine ) debería funcionar. Puede que ni siquiera necesites un dynamic_cast si está pasando el motor a un VanillaOptionFuture se fijará el futureExpiry mientras que si se pasa el motor a un miembro de datos VanillaOption lo ignorará. Dentro de calculate , sólo tiene que comprobar si futureExpiry es un nulo Date() .

La respuesta más larga es que el diagrama de clases que estás construyendo es un poco inestable. Estás partiendo de

class VanillaOptionFuture : public VanillaOption

que te permite evitar la duplicación de todo el código alrededor de los miembros de datos pero, en los modismos de C++, está diciendo "una opción vainilla en un futuro es un tipo particular de opción vainilla". Esto te permite evitar mucha duplicación de código, así que vamos con ello, pero puede desconcertar un poco al lector si está pensando que una opción vanilla es un activo opción. De todos modos, como he dicho, vamos con ello.

La relación entre los motores correspondientes, y va a ser complicado. No has dicho cómo piensas implementarlo, pero necesitas una nueva clase de argumento, así que también necesitas definir un nuevo VanillaOptionFuture::engine no se puede reutilizar la clase VanillaOption::engine cuya clase argumental es fija.

Posibilidad 1: si se hereda VanillaOptionFuture::engine de VanillaOption::engine En el caso de la opción de futuros, estás diciendo que un motor para una opción de futuros es un motor para una opción, lo que en tu caso parece correcto -tu motor puede cotizar ambos- pero no está garantizado en general, ya que un determinado motor para la opción de futuros podría depender de datos de futuros que no están disponibles en las opciones simples.

La posibilidad 2 es definir VanillaOptionFuture::engine como independiente de VanillaOption::engine y eludir el problema semántico. También puedes eludir el problema semántico optando por la posibilidad 1 y simplemente no pensando en ello. :)

En ambos casos, el compilador no se quejará; VanillaOption comprueba el tipo del motor sólo indirectamente, a través del tipo de su clase de argumentos, y ese será correcto ya que hereda VanillaOptionFuture::arguments de VanillaOption::arguments .

Ambas posibilidades funcionan, pero las relaciones entre las clases no están muy bien definidas, lo que puede hacer que el código sea confuso para los lectores. Sin embargo, como he dicho, QuantLib no tiene una forma correcta de hacer esto, así que la forma que propones me parece buena.