Question about Finite Differencing engine

[Joseph Wang]

Question: Is anyone working on refactoring the Vanilla options to use
the pricing engines for finite differencing?  I'd rather use the new
architectural in order to price convertible bonds, and as an exercise to
help me understand the code, I can do some work to create a finite
difference pricing engine.  The code in finite difference itself seems
generic enough so that doesn't have to be rewritten.

[Ferdinando M. Ametrano-3]

At 02:11 PM 2/1/2005, Joseph Wang wrote:
>Is anyone working on refactoring the Vanilla options to use the pricing
>engines for finite differencing?

It's been on the todo list forever. Let's get it straight: the refactoring
of Vanilla options should not be needed, it's just matter of adding Finite
Difference engine(s) for Vanilla options.
Even "moving" the existing FD code into the Pricing Engine framework would
be great.

>   I'd rather use the new architectural in order to price convertible
> bonds, and as an exercise to help me understand the code, I can do some
> work to create a finite difference pricing engine.
Oh please, you're welcome!

BTW take a look at the MC engines in order to exploit as mush as possible
for the FD engines (e.g. time discretization, control variate, etc.)

>   The code in finite difference itself seems generic enough so that
> doesn't have to be rewritten.
It could be vastly improved... anyway let's not make "best" enemy of "better."

ciao -- Nando

[Joseph Wang]

Ferdinando Ametrano wrote:

> At 02:11 PM 2/1/2005, Joseph Wang wrote:
>
>> Is anyone working on refactoring the Vanilla options to use the
>> pricing engines for finite differencing?
>
>
> It's been on the todo list forever. Let's get it straight: the
> refactoring of Vanilla options should not be needed, it's just matter
> of adding Finite Difference engine(s) for Vanilla options.
> Even "moving" the existing FD code into the Pricing Engine framework
> would be great.
>

Great!!!  I'll start trying to "wrapper" some of the simpler option
engines.  It looks pretty straightforward.  So straightfoward that I was
worried that I was missing some deep architectural reason why it had not
been done before
:-) :-)

>
> BTW take a look at the MC engines in order to exploit as mush as
> possible for the FD engines (e.g. time discretization, control
> variate, etc.)
>
Sure.....

>>   The code in finite difference itself seems generic enough so that
>> doesn't have to be rewritten.
>
> It could be vastly improved... anyway let's not make "best" enemy of
> "better."

One of the nice things about "porting" the fd pricers into the pricing
engine framework is that it adds a layer of decoupling between the fd
engine and the user API.......

I'll try to get something out in the next week or two.

[Joseph Wang]

Yuck....  Ran into the first problem.....

The current Fd interfaces expect numbers for risklessRate and
dividendYields and don't know anything about the YieldTermStructures......

What is the suggested way of getting an input for the finite
differencing routines.

I'm thinking that

process->zeroRate(time, Continuous)->Rate();

would do it.

Also, anything thoughts on the "right way" of doing this.  It seems to
me that in order to get the finite difference model to handle
YieldTermStructures would require some extensive changes in the engine.  
On the bright side, it seems that it only has to get done once.

The strategy that I'm thinking about doing is to put in the 'quick and
dirty' single number rate in and get everything working, and then try to
put in YieldTermStructures.

[Luigi Ballabio]

On 02/02/05 06:57:04, Joseph Wang wrote:
>
> What is the suggested way of getting an input for the finite differencing  
> routines.
>
> I'm thinking that
>
> process->zeroRate(time, Continuous)->Rate();
>
> would do it.

Rate r = process->riskFreeRate()->zeroRate(time, Continuous);

will do the trick: there's no need of the last ->rate() as a conversion  
operator from InterestRate to Rate is provided.

> Also, anything thoughts on the "right way" of doing this.  It seems to me  
> that in order to get the finite difference model to handle  
> YieldTermStructures would require some extensive changes in the engine.

Hmm, I'm not sure. Shouldn't be a matter of initializing the differential  
operator properly?

> On the bright side, it seems that it only has to get done once.
> The strategy that I'm thinking about doing is to put in the 'quick and  
> dirty' single number rate in and get everything working, and then try to  
> put in YieldTermStructures.

Good plan :)

Later,
        Luigi

----------------------------------------

The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum

[Joseph Wang]

Luigi Ballabio wrote:

>> Also, anything thoughts on the "right way" of doing this.  It seems
>> to me  that in order to get the finite difference model to handle  
>> YieldTermStructures would require some extensive changes in the engine.
>
>
> Hmm, I'm not sure. Shouldn't be a matter of initializing the
> differential  operator properly?
>
Yes, but it will require a lot of new changes to pass the
yieldtermstructure and Volatility to the place where it can set the
operator.

By the way, this may be a simple question, but how does one create a
constant yieldtermstructure and constant volatility.  What I'd like to
do is to make changes to the finite difference engine to handle the term
structures and term volatities, and then reimplement the current
constructors to call the new interface with constant interest rates and
volatities.  This will make things backward compatible, so that people's
current code doesn't break (always a good thing).

[Joseph Wang]

I've attached the first pass at a european pricing engine at

http://wiki.quantlib.org/twiki/bin/view/Quantlib/FiniteDifferencePricingEngines

It includes a unit test which seems to pass.

Over the next week or two, I'd like to modify the finite difference
engine and the old pricers to take into account term structures for the
European options.

[Luigi Ballabio]

On 02/03/05 06:48:13, Joseph Wang wrote:
> I've attached the first pass at a european pricing engine at
>
> http://wiki.quantlib.org/twiki/bin/view/Quantlib/FiniteDifferencePricingEngines
>
> It includes a unit test which seems to pass.

I've included it into CVS---thanks.

Later,
        Luigi


----------------------------------------

The idea that an arbitrary naive human should be able to properly use a  
given tool without training or understanding is even more wrong for  
computing than it is for other tools (e.g. automobiles, airplanes, guns,  
power saws).
-- Doug Gwyn

[Ashish Kulkarni-6]

Joseph Wang wrote:

> By the way, this may be a simple question, but how does one create a 
> constant yieldtermstructure and constant volatility.  What I'd like to 
> do is to make changes to the finite difference engine to handle the term 
> structures and term volatities, and then reimplement the current 
> constructors to call the new interface with constant interest rates and 
> volatities.  This will make things backward compatible, so that people's 
> current code doesn't break (always a good thing).

Take a look at the following classes:

FlatForward 	  http://www.quantlib.org/reference/a01243.html
BlackConstantVol  http://www.quantlib.org/reference/a01088.html

Greetings!

ICICI Infotech is now 3i Infotech.

The e-mail addresses of the company's employees have been changed to <existing name>@3i-infotech.com. You are requested to take note of this new e-mail ID and make use of the same in future

"This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and associated companies, (collectively "3i Infotech"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects."