Inflation Questions (repeated)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Inflation Questions (repeated)

Peter Caspers-4
Hi,

    since currently there seem to be a few people active in the
inflation part of the library, may I resend the question below ( I
hope I did not get an answer, at least I do not remember ) ?

Thanks
Peter


Hi,
just as an update to the point below: The second way of interpolating
seems to be the correct one. I do not have a suggestion for a fix in
ql however (as I said below, everything under the assumption that my
understanding of the intended usage of the classes is correct).
I have a second question on inflation in ql concerning the yoy
volatility structure. I am trying to use a
KInterpolatedYoyOptionletVolatilitySurface. Retrieving a volatility
for say maturity = 1y and a strike k the following happens:
1 YoYOptionletVolatilitySurface::volatility( today + 1y , k ) is
called. The observation lag (3m) is subtracted from the maturity date
and the time to reference date is computed giving (apprx.) t = 0.75.
Then volatilityImpl(t,k) is called =>
2 KInterpolatedYoYOptionletVolatilitySurface::volatilityImpl(t,k)
recomputes a physical date d from t=0.75 giving something like d =
today+9m and then retrieves a volatility slice for this d from the
yoyOptionletStripper, which is in my case an
InterpolatedYoYOptionletStripper =>
3 InterpolatedYoYOptionletStripper::slice(d) computes for each
relevant strike k a volatility by invoking volatility(d,k) on the
respective volatility curve. The latter is a
PiecewiseYoYOptionletVolatilityCurve. This triggers executiion of
4 YoYOptionletVolatilitySurface::volatility( today +9m , k ) which we
already had above. Again the observation lag (3m) is subtracted and we
arrive at today + 6m and (apprx.) t = 0.5, which is used as input to
5 InterpolatedYoYOptionletVolatilityCurve::volatilityImpl(t) which
finally returns the volatility for t=0.5.
It should be t=0.75 in my opinion however. I do not have a general
fix, but only a workaround changing the call in 2 into
slice_ = yoyOptionletStripper_->slice(d + this->observationLag() );
which should work if the default observation lag is used in 1.
Is my observation correct and would you consider the workaround more
or less reasonable ?
Thanks a lot for any input
Peter

---------- Forwarded message ----------
From: Peter Caspers <[hidden email]>
Date: 2012/12/17
Subject: Inflation Index Interpolation
To: [hidden email]


Hi,
I am comparing Murex and QuantLib concerning Inflation Pricing. I
observe a difference in the way an index fixing is interpolated
between known (i.e. already fixed) values. Here is an example:
Take the EUHICP XT index which has fixings
01.08.2012 (Aug 12) 115.10
01.09.2012 (Sep 12) 115.97
Now I want to look up the fixing on 28.08.2012 belonging to an
observation date on 28.11.2012 (3m observation lag). In QL the
interpolation is done as follows:
Days between 01.08. and 01.09. = 31, Days between 01.08. and 28.08. =
27, Interpolated Fixing = 115.10 + 27/31 * ( 115.97 - 115.10 )
In Murex on the opposite:
Days between 01.11. and 01.12. = 30, Days between 01.11. and 28.11. =
27, Interpolated Fixing = 115.10 + 27/30 * ( 115.97 - 115.10 )
Which computation is the correct one, i.e. what is the market
convention that is actually applied to deals ? Maybe I am using the QL
classes not as intended ?
Thanks a lot
Peter

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users