Login  Register

RE: isTimeDependent ???

Posted by cuchulainn on Oct 02, 2005; 2:52pm
URL: http://quantlib.414.s1.nabble.com/isTimeDependent-tp4060p4066.html

Re: [Quantlib-users] isTimeDependent ???
Joseph,
 
I think this depends on user requirements.  There is a trade-off between
keeping track of these things so that the library figures out these
things and letting the user use the library in ways that aren't
mathematically correct but gets you a quick and dirty answer.

 

DD yes, I know the problem. In this case a nice solution is aesthetically please but for performance reasons a less general solution has to be acceptd.



For example, one thing that bothers me is that we have an american
engine and a european engine. 
 
DD with FDM? or in general?
One way is to use the penalty method PDE (for euro, penalty is zero).
The only difference is the constraint condition?
 
It would seem to me that you'd define
american and european in the instrument and then have the pricing
engines figure out how to price them.  Where this would break is if you
have a situation in which you have an american option and for whatever
reason want to use a european pricing engine against it.
DD This situation should not be alllowed of course. An idea is the Abstract Factory pattern so that we can create consistent product families, e.g. Euro option object ONLY with a a Euro engine. Should be transparent to the client.
Also, the Template Method pattern is a possibility (default is Euro and define your own s/w hooks)

Where this bothered me was if you use the analytic pricing engines
against instruments with changing interest rates, you will get the wrong
answer.  The idea behind having an isTimeDependent flag is to at least
warn the user that they are going to get the wrong answer.  On the other
hand, if it is common practice to use engines in a way that doesn't give
you the exact answer, then maybe this would cause more problems than it
is worth.
DD do you have a UML class diagram for this configuration? Then one can see the design blueprint. This is always the first thing I think about before coding.
 
Remarks: Using flags is tricky, and not OO. I am not saying it is bad. What I am saying is that there is a lonely pattern trying to escape.
 
Hope this is of some use.
 
Daniel

 

From: Joseph Wang [mailto:[hidden email]]
Sent: Sat 01/10/2005 17:23
To: Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] isTimeDependent ???

I think this depends on user requirements.  There is a trade-off between
keeping track of these things so that the library figures out these
things and letting the user use the library in ways that aren't
mathematically correct but gets you a quick and dirty answer.

For example, one thing that bothers me is that we have an american
engine and a european engine.  It would seem to me that you'd define
american and european in the instrument and then have the pricing
engines figure out how to price them.  Where this would break is if you
have a situation in which you have an american option and for whatever
reason want to use a european pricing engine against it.

Where this bothered me was if you use the analytic pricing engines
against instruments with changing interest rates, you will get the wrong
answer.  The idea behind having an isTimeDependent flag is to at least
warn the user that they are going to get the wrong answer.  On the other
hand, if it is common practice to use engines in a way that doesn't give
you the exact answer, then maybe this would cause more problems than it
is worth.


Daniel J. Duffy wrote:


> Bridge pattern?

>
> ------------------------------------------------------------------------
> *From:* [hidden email] on behalf of Joseph
> Wang
> *Sent:* Fri 30/09/2005 16:18
> *To:* [hidden email];
> [hidden email]
> *Subject:* [Quantlib-users] isTimeDependent ???
>
> What do people think about adding an "isTimeDependent()" method to
> things like TermStructure?  This would be defaulted to "true" as a
> virtual function which subclasses could then set to false.
>
> The reason for this is that then the pricing engines could really make
> use of this information to decide whether or not to optimize a
> calculation.  For finite difference methods this could be a huge time
> saver, and simplify the code considerably.
>
> The way that it would work is that the finite difference engine would
> find out whether the calcuation matrix is time dependent or not, the
> calculation matrix would find out from the process, the process would
> find out from the interest and volatility term structures.
>
> Thoughts?
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>