Re: [Quantlib-dev] Some questions

[Ferdinando A. <fer...@am...>]

Hi all


>>In vanilla option:
>>we should not input a volatility. It should be the pricer that has a Black
>>model (a volatility) as an input... the volatility is part of the model, not
>>of  the instrument, IMHO.
>
>Kind of makes sense. Even though only exercise date, strike and type are 
>really part of the instrument---the yield term structure could be 
>considered part of the model too, and the current underlying price is a 
>market datum. People?
This question raises a good point.
The first problem I see is the definition of 'model'.
We currently have FiniteDifferenceModel and MonteCarloModel, but I would 
say their names can be misleading, since a model is not strictly related to 
the numerical approach used to implement it.
Is a PricingEngine (analityc, FD, MC) a model or an object used to perform 
calculation for different models?

Take the Black (market) vol surface for an equity index as a concrete 
example. This is a market observable, model independent.

Different models extract their own volatility from this surface in 
different ways: the Black model would just interpolate on this surface, 
while Derman/Kani would extract local volatilities for the underlying's 
stochastic process. These volatilities do belong to the model, the Black 
surface doesn't.

So I see 3 components here: a description of the market (the yield curve, 
the Black surface, etc.), a model (eg. constant volatility Black model, 
time dependant volatility, time/strike dependent volatility), and a 
numerical approach (analytic, FD, MC).
Should the market description be an input of the Instrument/model/both?

What about the dividend yield term structure? It probably belongs to the 
"underlying" of the option, but ... what if I want to model a stochastic 
process for dividends?

Many questions and few answers, I know.
I would suggest that we try to have a realistic general design, carefully 
avoiding design paralysis. I would define a good design the one that solves 
our _current_ problems. The price to pay is to have to refactor the code later.

>>Why not have a single instrument class, that would be nearly the same as the
>>present Option class? Stocks and swaps could then be priced with appropriate
>>pricing engines (see 3))... A swap, for example, could be priced on two
>>different term structures (Andre had to add a method to do this), or priced
>>with finite-difference methods for didactical purposes.
>Good thinking. We can just give Instrument::performCalculation the 
>implementation currently in Option.
I agree

>>How do we know in which currency the NPV is given? Instruments should have a
>>currency method...
>Or maybe a Money structure could be returned with an amount and a currency.
>The same could hold for nominals and prices.
I agree, but I would be careful to enforce this as long as we don't settle 
on a "Currency" design. That is, should I check that the yield curve 
provided to my swap has the same currency of the swap nominal? As long as 
these details are not clear I would prefer the user to take the charge of 
aggregating all the instruments of a given currency.

>I would like some way to pass a Stock instance or one of  its attributes as
>the underlying, in the construction of a VanillaOption instance.
I like this approach

>Of course, we could define the underlying to be an Instrument, but if the
>option is in fact an FX option, what do we do? Do we define Cash/Money to be
>an instrument?
I would say that Cash/Money is an instrument accruing interest and subject 
to cross currency risk.

>I think there are some american options that cannot be exercised before a
>starting date. That's why AmericanExercise instances are constructed using
>AmericanExercise(Date earliestDate, Date latestDate). This is also the way
>FpML implements the american exercise type. So, the present interface of
>VanillaOption cannot handle this case. Perhaps we should replace
>"Date exerciseDate" by "Exercise exercise".
I agree.

ciao -- Nando