isTimeDependent ???
Locked
 
|
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? |
|
|
I think the end goal is great, but it would be great if instead of
checking booleans, the decision of whether to optimize would be made in
an OO-manner somehow.
On 9/30/05, Joseph Wang <[hidden email]> wrote: What do people think about adding an "isTimeDependent()" method to |
Re: [Quantlib-dev] isTimeDependent ???
|
|
In reply to this post by Joseph Wang
On 09/30/2005 04:18:51 PM, Joseph Wang wrote:
> 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. I would leave that to the user. Namely, I would rather add an isTimeDependent parameter to the engine constructor, defaulting to false. If enabled, the engine would optimize the calculation. It seems to me to have two advantages: 1) it doesn't try to be too smart, which is often more difficult that it's worth; 2) it makes it possible to optimize the calculation even when the term structures are not constant; a user could take a time-dependent term structure, and still decide that for a simple European option he can just use the zero-yield to maturity. Luigi ---------------------------------------- Newton's Law of Gravitation: What goes up must come down. But don't expect it to come down where you can find it. Murphy's Law applies to Newton's. |
|
|
In reply to this post by Joseph Wang
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 |
|
|
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 > |
|
|
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 |
|
|
In reply to this post by Joseph Wang
On 10/01/2005 05:23:13 PM, Joseph Wang wrote:
> 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. > > Where this bothered me was if you use the analytic pricing engines > against instruments with changing interest rates, you will get the > wrong answer. Not necessarily---for an European option, simply using the zero-yield to maturity gives you the right price, not an approximation (the actual shape of the yield term structure doesn't matter, only its integral.) The principle I would stick to is that users know better. I'm afraid that trying to have the library do what it thinks the Right Thing might prevent users to do what they know to be the right thing. Later, Luigi ---------------------------------------- Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. |
Question on Caps/Floors pricing on InArrear cashflows.
|
|
Hi all,
Within Quantlib you can create an array of cashflows which can then be passed into the CapFloor constructor. My question is whether the pricing logic within the CapFloor class is correct for InArrear cashflows? The CapFloor class takes as it's exercise date for all the caplet's/floorlet's the fixing date of the coupon. Under a UpFrontIndexedCoupon this would be settleDays before the start date of the period. Under an Inarrearindexedcoupon this would be settleDays before the end date of the period. Thus when pricing a caplet/floorlet which is based on an Inarrearindexedcoupon, should the exercise date still be settleDays before the start date of the period? My guess is that the exercise date should be settleDays before the start date of the period. Best Regards, Toyin Akin. |
|
|
In reply to this post by Luigi Ballabio
Maybe the way to have both "smart libaries" and "smart users" is to have
a singleton factory class which takes an instrument and then set it with the best guess pricing engine. For example PricingEngineHelper::setToFiniteDifference(instrument) setToBinomialTree setToMonteCarlo Luigi Ballabio wrote: > > On 10/01/2005 05:23:13 PM, Joseph Wang wrote: > >> 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. >> >> Where this bothered me was if you use the analytic pricing engines >> against instruments with changing interest rates, you will get the >> wrong answer. > > > Not necessarily---for an European option, simply using the zero-yield > to maturity gives you the right price, not an approximation (the > actual shape of the yield term structure doesn't matter, only its > integral.) > > The principle I would stick to is that users know better. I'm afraid > that trying to have the library do what it thinks the Right Thing > might prevent users to do what they know to be the right thing. > > Later, > Luigi > > > ---------------------------------------- > > Hanlon's Razor: > Never attribute to malice that which is adequately explained > by stupidity. |
| Free forum by Nabble | Edit this page |