Some questions

[Sadruddin Rejeb-3]

Hello guys,
Since there's a big refactoring going on, I'd like to share a few ideas that
have occured to me this afternoon in the train, while browsing the source.

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

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

3)
Define a generic MarketPricingEngine that just returns the value of a market
element.

4)
How do we know in which currency the NPV is given? Instruments should have a
currency method...

5)
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.
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?

Thanks for reading all this,
Sad.

--
---\ Sadruddin Rejeb \-----
----\ [phone] \----
-----\ [hidden email] \---

[Luigi Ballabio-4]

Hi Sad,

At 1:44 AM +0200 6/12/02, Sadruddin Rejeb wrote:
>1)
>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?

Also,
s/a volatility/a volatility term structure/
(and let's see how many people blink at the above :)


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


>3)
>Define a generic MarketPricingEngine that just returns the value of a market
>element.

If it's for the sake of pricing stocks, we can just override
performCalculations in the Stock class to short-circuit the pricing
engine.


>4)
>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. But I'm not sure about this.
Anyway, I agree that the problem exists.


>5)
>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.
>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'm not getting this, but then again, it's 11pm.
Would you pseudo-code an example? A couple of constructors, for instance?

Bye for now,
                Luigi

[Sadruddin Rejeb-3]

Hi Luigi,

> If it's for the sake of pricing stocks, we can just override
> performCalculations in the Stock class to short-circuit the pricing
> engine.

Sure, but I was thinking of a generic pricer that would apply to all
instruments directly quoted as prices. If for example, I have a plain-vanilla
option in my portfolio, I may want that its NPV is directly linked to some
market price.

>>5)
>>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.
>>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'm not getting this, but then again, it's 11pm.
>Would you pseudo-code an example? A couple of constructors, for instance?

Yeah, I agree it's not crystal-clear. It may even be completly naive.
What I meant is:
If I have a Stock instance, and I want to define an option on it, how can I
do this if I don't have access to the MarketElement linked to the stock
 price? What I was thinking is that we may want the underlying to be an
 instrument instead of a MarketElement.

Then, I have other questions. Does the VanillaOption class refer to
stock-options only, or is it supposed to include FX vanilla-options?
And are we going to define another class for american options?

Later,
Sad

[Luigi Ballabio-4]

At 11:37 AM 6/13/02 +0000, Sadruddin Rejeb wrote:
> > If it's for the sake of pricing stocks, we can just override
> > performCalculations in the Stock class to short-circuit the pricing
> > engine.
>Sure, but I was thinking of a generic pricer that would apply to all
>instruments directly quoted as prices. If for example, I have a plain-vanilla
>option in my portfolio, I may want that its NPV is directly linked to some
>market price.

Oh, ok, I see that. I agree.

> >>5)
> >>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.
> >>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'm not getting this, but then again, it's 11pm.
>
>What I meant is:
>If I have a Stock instance, and I want to define an option on it, how can I
>do this if I don't have access to the MarketElement linked to the stock
>  price? What I was thinking is that we may want the underlying to be an
>  instrument instead of a MarketElement.

And then call NPV() instead of value(). Yes, I agree.


>Then, I have other questions. Does the VanillaOption class refer to
>stock-options only, or is it supposed to include FX vanilla-options?
>And are we going to define another class for american options?

As for the American, one just has to pass an American engine to the
VanillaOption.

As for FX options, VanillaOption could be used if they take the same
parameters. However, I'm not sure that it wouldn't be better to
differentiate the two just for ease of understanding.

Thoughts?

         Luigi

[Andre Louw-2]

Hi,

Agree with Luigi, just 2 cents worth additionally:

> >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. But I'm not sure
> about this.
> Anyway, I agree that the problem exists.
>

It is definately a problem, especially when multi-currency instruments are
involved. a Money structure is a good idea. Any value where a currency is
involved would need to return this.

Andre
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Sadruddin Rejeb-3]

Hi Luigi,
> As for the American, one just has to pass an American engine to the
> VanillaOption.
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".

Sad

[Ferdinando M. Ametrano-2]

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

[Luigi Ballabio-4]

At 12:43 PM 6/14/02 +0200, Ferdinando Ametrano wrote:
>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.

We're modeling apples and oranges here :)
Finite differences methods model _an equation_ by discretizing it.
Monte Carlo is more a technique than a model though.
Any ideas for a better name?


>Is a PricingEngine (analityc, FD, MC) a model or an object used to perform
>calculation for different models?

It is an engine, i.e., a calculation. The details of the latter most likely
depend on a model _and_ a numerical technique used for solving the
equations describing the model.


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

I'd say that what changes on a per-model basis belongs to specific models.


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

Beats me. We can leave where it is now and think about it when you'll 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.

_Emphasis_ and acting bold won't make your definition any better, you know.
Even though it's a standard meeting technique :)

I agree though. I think in this case we can make single incremental changes
(e.g., moving the volatility to the model and leave the yield curve alone
while we think about it) when single problems arise.

Bye,
         Luigi