|
|
At 03:48 PM 7/4/01 +0200, Gilbert Peffer wrote:
>Well, yes, me again :-) There is an abstract base clase Instrument from
>which are derived OTCInstrument. How is (or will) the Option class be
>married with the Instrument class? At the moment, the Option class looks to
>me like a pricing-oriented class. The question is how to implement the
>Instrument interface. Hope this makes sense,
It does make sense. Actually, this is a part of the library we are thinking
about right now. In time the picture should become the following:
1) OTCInstrument and PricedInstrument disappear - not much need for them.
2) Option and its derived classes (the ones in the Pricers folder) embody,
as you guessed, the pricing algorithms - they are not instruments as such.
Also, they take an underlying price rather than an instrument, or a
risk-free rate rather than a term structure upon which to determine it.
3) the current Option class is renamed to something that expresses the
above. The new Option class derives from Instrument. Such classes take more
high-level parameters; for instance, a given option would accept as inputs
a stock (i.e., an instrument) and a term structure, and in its
implementation it would get from them the underlying price and the
risk-free rate and pass the latter to the appropriate pricer to get its own
value.
Bear with us while we hammer at the code.
Thing should get better by release 0.2.0.
Someone who, unlike me, actually wrote the code for BSMOption and derived
classes will answer to the rest of the avalanche :)
Bye,
Luigi
|
Locked
