On Tue, 2008-04-29 at 01:50 -0700, Chris Kenyon wrote:
> We want to give users with the ability to provide a seasonality > correction to the term structures. > > The get/set is defined in the base InflationTermStructure class as: > > public: > void setSeasonality(const boost::shared_ptr<Seasonality> > &seasonality = boost::shared_ptr<Seasonality>()); > boost::shared_ptr<Seasonality> seasonality() const; > bool hasSeasonalityCorrection() const; I'm not sure that I like the setter. Of course observability can be implemented correctly, but I'd prefer curves to be immutables. What I'm worried about is the following scenario: Handle<InflationTermStructure> ts; InflationInstrument I1(..., ts); InflationInstrument I2(..., ts); I1.someResult(...); // for some reason, calls setSeasonality() at which point the value of I2 changes. We had such a bug in the past when calculating the implied volatility of an option would modify the underlying equity process for other instruments. It wasn't pretty. My proposal of adding seasonality by wrapping the curve was so that I1 could (if needed) take the passed term structure, wrap it, and use the wrapped curve without modifying the original one. Thoughts? Later, Luigi -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
I like the idea that curves are immutable. However, I'm not keen on introducing another level of coding structure. A simple solution would be to remove the setter. This way curves are immutable, and if a user wants different seasonalities they can just provide different curves ... this does seem like a normal way to go about things (to me). I don't favor using Quotes for seasonality data since seasonality should not be changing on short timescales (there are no market quotes - this is exactly why this feature was invented). Comments anyone? Regards, Chris ----- Original Message ---- From: Luigi Ballabio <[hidden email]> To: Chris Kenyon <[hidden email]> Cc: [hidden email]; [hidden email] Sent: Wednesday, April 30, 2008 12:19:00 PM Subject: Re: [Quantlib-dev] seasonality for inflation term structures On Tue, 2008-04-29 at 01:50 -0700, Chris Kenyon wrote: > We want to give users with the ability to provide a seasonality > correction to the term structures. > > The get/set is defined in the base InflationTermStructure class as: > > public: > void setSeasonality(const boost::shared_ptr<Seasonality> > &seasonality = boost::shared_ptr<Seasonality>()); > boost::shared_ptr<Seasonality> seasonality() const; > bool hasSeasonalityCorrection() const; I'm not sure that I like the setter. Of course observability can be implemented correctly, but I'd prefer curves to be immutables. What I'm worried about is the following scenario: Handle<InflationTermStructure> ts; InflationInstrument I1(..., ts); InflationInstrument I2(..., ts); I1.someResult(...); // for some reason, calls setSeasonality() at which point the value of I2 changes. We had such a bug in the past when calculating the implied volatility of an option would modify the underlying equity process for other instruments. It wasn't pretty. My proposal of adding seasonality by wrapping the curve was so that I1 could (if needed) take the passed term structure, wrap it, and use the wrapped curve without modifying the original one. Thoughts? Later, Luigi -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Hi Chris
On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <[hidden email]> wrote: > I don't favor using Quotes for seasonality data since seasonality > should not be changing on short timescales (there are no market > quotes - this is exactly why this feature was invented). > Comments anyone? I understand your reasons but I am in favor of Quotes, especially since they would be the main hook for sensitivity analysis, i.e. in order to calculate sensitivity with finite differences you just tweak the Quote value, recalculate the NPV of your portfolio, then restore the original value. The observability combined with the lazyness ensure optimal performances and general easiness for this approach, which is probably one of best features of the QuantLib design. ciao -- Nando ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
In reply to this post by Luigi Ballabio
Hi Nando, that makes sense. This also makes setSeasonality methods safer because if you are using Quotes it is a signal that you may be changing all sorts of other things. OK lets go that way because: 1) helps avoids unexpected side effects (i.e. given the QuantLib setup you know that if you change a quote, or if you have to make new ones, then you are doing something drastic); 2) permits sensitivity analysis (which is also what get/set are about). This implies: 1) Instead of vector<Real> we use a vector<Handle<Quote> > for seasonality factors. Have I understood what you meant? Any objections anyone? Regards, Chris ----- Original Message ---- From: Ferdinando Ametrano <[hidden email]> To: Chris Kenyon <[hidden email]> Cc: [hidden email]; [hidden email]; [hidden email] Sent: Thursday, May 1, 2008 6:19:32 PM Subject: Re: [Quantlib-dev] seasonality for inflation term structures Hi Chris On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <[hidden email]> wrote: > I don't favor using Quotes for seasonality data since seasonality > should not be changing on short timescales (there are no market > quotes - this is exactly why this feature was invented). > Comments anyone? I understand your reasons but I am in favor of Quotes, especially since they would be the main hook for sensitivity analysis, i.e. in order to calculate sensitivity with finite differences you just tweak the Quote value, recalculate the NPV of your portfolio, then restore the original value. The observability combined with the lazyness ensure optimal performances and general easiness for this approach, which is probably one of best features of the QuantLib design. ciao -- Nando ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
On Fri, 2008-05-02 at 00:57 -0700, Chris Kenyon wrote:
> This implies: > 1) Instead of vector<Real> we use a vector<Handle<Quote> > for > seasonality factors. Or we use either. Luigi -- The economy depends about as much on economists as the weather does on weather forecasters. -- Jean-Paul Kauffmann ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Free forum by Nabble | Edit this page |