inflation seasonality added to trunk

[Chris Kenyon-2]

Hi Luigi et al,

 

I’ve added in seasonality to the inflation termstructures (thanks to Piero Del Boca and myself), specifically:

 "

Seasonality

|

MultiplicativePriceSeasonality

 "

The code and tests have changed quite a lot from initial stages; there is a test for multi-year (non-stationary seasonality) and the other tests have changed as appropriate.

 

This update handles multiplicative seasonality in CPI/RPI/HICP, i.e. the input is the seasonality anticipated in the future prices (relative to some given base date).  The code then adjusts the Zero or YoY rates to produce the desired effect.  This handles stationary (one-year) seasonality and non-stationary (multi-year) seasonality with the same call – you just give more factors to get non-stationarity (but these must always be a multiple of the number expected for one year (defined by the frequency of the seasonality).  The factors are used repetitively, i.e. they wrap around.  Of course, if seasonality is stationary there is no effect on YoY rates - these only see an effect when there is different seasonality in successive years.

The effect of seasonality is always normalized relative to some base.  For Zero inflation the base is the start of the inflation termstructure - you have a fixing for that date so the correction must be one.  For YoY the base is one year before.  Hence ... see next paragraph.  This normalization is done in the code.  The seasonality factors can (and mostly will) have a different base date to the termstructure.

With non-stationary seasonality you can get inconsistency with the inflation termstructure that you give it to - this is checked explicitly (can be turned off in descendents).  The inconsistency can arise if you give seasonality factors that are different for integer years after the inflation termstructure start date (recall this is before the nominal because of lags) - because for (most/some?) of those dates you will have calibration instruments.

 

N.B the code handles daily seasonailty, however in this case the consistency tests are switched off.  Multi-year daily seasonality, in general, will never be consistent due to weekends, holidays, leap-years, etc.  You have been warned!

Best regards,

Chris

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

_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Sun, 2009-06-28 at 07:44 -0700, Chris Kenyon wrote:

> I’ve added in seasonality to the inflation termstructures (thanks to
> Piero Del Boca and myself)

Chris,
        thanks. From a cursory glance, it seems ok. Just two things:

1) setSeasonality changes the rates returned by the curve methods, so it
should notify observers of the curve that something has changed;
2) I don't think you need a separate boolean hasSeasonalityCorrection_,
since you can write hasSeasonality() just as
    return seasonality_;
(shared pointers are converted to booleans like ordinary pointers.)

I can make the changes if you agree with them.

Later,
        Luigi


--

A debugged program is one for which you have not yet found the
conditions that make it fail.
-- Jerry Ogdin



------------------------------------------------------------------------------
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Chris Kenyon-2]

Luigi,

1) agreed
2) agreed

Please do make those changes.

Ciao,
Chris

---

From: Luigi Ballabio <[hidden email]>
To: Chris Kenyon <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]
Sent: Monday, June 29, 2009 10:31:30 AM
Subject: Re: inflation seasonality added to trunk

On Sun, 2009-06-28 at 07:44 -0700, Chris Kenyon wrote:

> I’ve added in seasonality to the inflation termstructures (thanks to
> Piero Del Boca and myself)

Chris,
    thanks. From a cursory glance, it seems ok. Just two things:

1) setSeasonality changes the rates returned by the curve methods, so it
should notify observers of the curve that something has changed;
2) I don't think you need a separate boolean hasSeasonalityCorrection_,
since you can write hasSeasonality() just as
    return seasonality_;
(shared pointers are converted to booleans like ordinary pointers.)

I can make the changes if you agree with them.

Later,
    Luigi


--

A debugged program is one for which you have not yet found the
conditions that make it fail.
-- Jerry Ogdin

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

_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev