Re: SmileSection
Locked
 
|
Hi Nando, virtual is better because some of the time processing gets involved. I'd like the following virtual: virtual void initializeExerciseTime() const; // currently not virtual virtual Real varianceImpl(Rate strike) const; // currently not virtual virtual Volatility volatilityImpl(Rate strike) const = 0; // OK i.e. I need the calculation parts virtual. Exercise time, for inflation, could mean time-for-volatility-to-build-up OR time-from-referenceDate()-to-exercise. For interest rates these are the same. Having exercise time virtual gives more possibilities for descendants to change things. At a pinch I could make do with only varianceImpl(Rate strike) as virtual. Best, Chris From: Ferdinando Ametrano <[hidden email]> To: [hidden email] Cc: Chris Kenyon <[hidden email]> Sent: Tue, October 20, 2009 12:07:45 PM Subject: Re: SmileSection On Tue, Oct 20, 2009 at 10:22 AM, Luigi Ballabio <[hidden email]> wrote: > Chris needs to modify slightly the SmileSection class in order to make > it work for inflation volatility, namely, > >> For the volatility stripping the SmileSection class is unusable for >> inflation because of assumptions on timing. [...] mostly on how much >> time has passed up to T. For inflation time starts passing from >> (referenceDate-Lag, adjusted by interpolation setting) rather than >> just referenceDate. [...] To enable reuse most of its methods should >> be virtual then I could use it. > > As you (Nando) are the one with the design most clearly in mind, I > thought I'd refer Chris to you so that the two of you can work it out. > Let me know what you come up with (in the next few days, possibly?) it's ok for me to make it virtual, or just add a default null lag to the base class, whatever makes more sense ciao -- Nando PS this and other questions (e.g. bachelier) would be probably better discussed on the mailing list, where others might join with better insight... ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Tue, 2009-10-20 at 05:46 -0700, Chris Kenyon wrote:
> virtual is better because some of the time processing gets involved. > I'd like the following virtual: > > virtual void initializeExerciseTime() > const; // currently not virtual > virtual Real varianceImpl(Rate strike) const; > // currently not virtual > virtual Volatility volatilityImpl(Rate strike) const = 0; > // OK Ok--seeing as Nando agreed, I'll do that. Unless given a shout, I'll also fix a couple of other things I've seen in SmileSection, namely, the derived SpreadedSmileSection being declared as a friend and the SabrSmileSection class being defined in the same file. Luigi -- Grabel's Law: 2 is not equal to 3 -- not even for large values of 2. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Chris Kenyon-2
On Tue, Oct 20, 2009 at 2:46 PM, Chris Kenyon <[hidden email]> wrote:
> Exercise time, for inflation, > could mean time-for-volatility-to-build-up OR > time-from-referenceDate()-to-exercise. For interest rates these are the > same. Having exercise time virtual gives more possibilities for descendants > to change things. At a pinch I could make do with only varianceImpl(Rate > strike) as virtual. mmm... I'm not familiar enough with inflation to really challenge your proposal, so for me it's OK. Anyway I wonder if we might reserve exerciseTime for time-from-referenceDate()-to-exercise and then deal with time-for-volatility-to-build-up in volatilityImpl / varianceImpl. Would this choice make your code more complex or unnatural ? I.e. add a varianceTime (time-for-volatility-to-build-up) when it is not equal to exerciseTime (time-from-referenceDate()-to-exercise) ciao -- Nando ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Luigi Ballabio
On Tue, 2009-10-20 at 15:09 +0200, Luigi Ballabio wrote:
> Unless given a shout, I'll > also fix a couple of other things I've seen in SmileSection, namely, the > derived SpreadedSmileSection being declared as a friend and the > SabrSmileSection class being defined in the same file. Oh---and also smileSection->volatility(Null<Real>()) returning the ATM volatility [*], when there's a perfectly serviceable atmLevel method that can be used for writing volatility(atmLevel()). Luigi [*] Yes, I know it would be called as smileSection->volatility(), but that doesn't make much sense either, does it? :) -- Innovation is hard to schedule. -- Dan Fylstra ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Ferdinando M. Ametrano-3
On Tue, 2009-10-20 at 15:11 +0200, Ferdinando Ametrano wrote:
> On Tue, Oct 20, 2009 at 2:46 PM, Chris Kenyon <[hidden email]> wrote: > Anyway I wonder if we might reserve exerciseTime for > time-from-referenceDate()-to-exercise and then deal with > time-for-volatility-to-build-up in volatilityImpl / varianceImpl. > Would this choice make your code more complex or unnatural ? > I.e. add a varianceTime (time-for-volatility-to-build-up) when it is > not equal to exerciseTime (time-from-referenceDate()-to-exercise) I raise: why is exerciseTime() public when it's only used internally? Luigi -- Never mistake motion for action. -- Ernest Hemingway ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Luigi Ballabio
On Tue, Oct 20, 2009 at 3:25 PM, Luigi Ballabio
<[hidden email]> wrote: > Oh---and also smileSection->volatility(Null<Real>()) returning the ATM > volatility [*], when there's a perfectly serviceable atmLevel method > that can be used for writing volatility(atmLevel()). The point here is: 1) to have the interface gracefully degrade to the flat-smile case 2) the traders I work for claim it's too much effort to specify a strike even for non-flat smile, since unless differently specified, volatility tout-court is the atm one of course the second point is relevant for the application level so I will deal with it in QuantLibAddin if you want to change it in QuantLib > why is exerciseTime() public when it's only used internally? no strong reason beside he fact that all termstructures' interfaces are also time based so it might be sensible for a smile to know where it stands along the time dimension ciao -- Nando ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Ferdinando M. Ametrano-3
hmmmm, as a top-level interface I'd be keen not to add more internal methods to SmileSection. I.e. why do any calculations there at all? I'd suggest having the Impl's as virtual and having nothing else. I.e. do not do anything in the volatility and variance methods except calls the implementations. This would leave all time questions to the descendents, i.e. out of the interface. In fact why bother with Impl methods at all? Why not just make volatility and variance virtual? PIMPL is handy when the implementers can be changed (i.e. ptr to another class) but just calling another method doesn't really seem to qualify. Just my musings. From: Ferdinando Ametrano <[hidden email]> To: Chris Kenyon <[hidden email]> Cc: [hidden email] Sent: Tue, October 20, 2009 2:11:24 PM Subject: Re: SmileSection On Tue, Oct 20, 2009 at 2:46 PM, Chris Kenyon <[hidden email]> wrote: > Exercise time, for inflation, > could mean time-for-volatility-to-build-up OR > time-from-referenceDate()-to-exercise. For interest rates these are the > same. Having exercise time virtual gives more possibilities for descendants > to change things. At a pinch I could make do with only varianceImpl(Rate > strike) as virtual. mmm... I'm not familiar enough with inflation to really challenge your proposal, so for me it's OK. Anyway I wonder if we might reserve exerciseTime for time-from-referenceDate()-to-exercise and then deal with time-for-volatility-to-build-up in volatilityImpl / varianceImpl. Would this choice make your code more complex or unnatural ? I.e. add a varianceTime (time-for-volatility-to-build-up) when it is not equal to exerciseTime (time-from-referenceDate()-to-exercise) ciao -- Nando ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Tue, 2009-10-20 at 07:16 -0700, Chris Kenyon wrote:
> In fact why bother with Impl methods at all? Why not just make > volatility and variance virtual? PIMPL is handy when the implementers > can be changed (i.e. ptr to another class) but just calling another > method doesn't really seem to qualify. Just my musings. In this case it's not pimpl, it's Template Method. I guess it was written this way to mimic the other term structures, even if there's no added functionality in this case (there could be, though---e.g., in volatility() one could check the strike limits.) Luigi -- Lubarsky's Law of Cybernetic Entomology: There is _always_ one more bug. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Ferdinando M. Ametrano-3
On Tue, 2009-10-20 at 16:06 +0200, Ferdinando Ametrano wrote:
> On Tue, Oct 20, 2009 at 3:25 PM, Luigi Ballabio > <[hidden email]> wrote: > > Oh---and also smileSection->volatility(Null<Real>()) returning the ATM > > volatility [*], when there's a perfectly serviceable atmLevel method > > that can be used for writing volatility(atmLevel()). > > The point here is: > 1) to have the interface gracefully degrade to the flat-smile case > 2) the traders I work for claim it's too much effort to specify a > strike even for non-flat smile, since unless differently specified, > volatility tout-court is the atm one Well, I'm a lazy Italian myself, but in this case I'd go for clarity :) > > why is exerciseTime() public when it's only used internally? > no strong reason beside he fact that all termstructures' interfaces > are also time based so it might be sensible for a smile to know where > it stands along the time dimension Point taken. It stays public then. On the other hand, initializeExerciseTime should be protected, right? Luigi -- Glendower: I can call spirits from the vasty deep. Hotspur: Why, so can I, or so can any man; But will they come when you do call for them? -- King Henry the Fourth Part I, Act III, Scene I ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Tue, Oct 20, 2009 at 5:10 PM, Luigi Ballabio
<[hidden email]> wrote: > initializeExerciseTime should be protected, right? yes it should. And just to get the record straight in public: I trust you on whatever design re-factoring you might perform. Always. :-) ciao -- Nando PS ok, well... almost always ;-) ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Tue, 2009-10-20 at 18:22 +0200, Ferdinando Ametrano wrote:
> And just to get the record straight in public: I trust you on whatever > design re-factoring you might perform. Always. :-) ...provided that I understand the underlying financial point, that sometimes you have to beat into my thick skull :) Thanks for the kind words, though. Luigi P.S. Oh, and I've committed the changes. The class should be more or less ok now. -- There are no rules of architecture for a castle in the clouds. -- Gilbert K. Chesterton ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |