Swaption Volatility...

[Toyin Akin-3]

Hi,

 

Do you guys plan to model the whole Swaption Cube? (Exercise, Underlying and Strike).

Or are you guys looking to model the smile in some sort of way?

 

It seems like your current implementation handles only ATM Swaptions.

 

Toy.

 

[Luigi Ballabio-4]

At 07:48 PM 3/11/02 +0000, Toyin Akin wrote:
>Do you guys plan to model the whole Swaption Cube? (Exercise, Underlying
>and Strike).
>Or are you guys looking to model the smile in some sort of way?
>
>It seems like your current implementation handles only ATM Swaptions.

As a matter of fact, it does.
I don't think we'll go and try to model the smile for the time being. But I
think I'll put a hook there so that we can add the smile eventually
("eventually" seems to be a recurrent word in my replies lately, doesn't it?)

Bye,
         Luigi

[Toyin Akin-3]

Hey guys,

When you say "As a matter of fact, it does", do you mean that it does handle
Strikes, underlying, option mat, or it does handle ATM vols only. If the
former, I would have thought that you needed
a cube to represent your data and an interpolation scheme to handle this.

In addition, even though your class is called SwaptionVolatilityMatrix, it
can easily handle
cap/floor vols (or should that be caplet and floorlet vols), Basically
underlyings less than one year.

Your class does not seem to hold any strike info at all.

I think it would be a shame if the strikes were omitted as a user can just
construct your new
vol object and then promtly forget about handling/generating them when
pricing vanilla options.
A simple volatility() call would make my life sweet. In the current scheme,
I would have to
acquire the ATM vol and then adjust it on the outside. Painful!!

Then again, I could have read the code wrong and thus I'm talking complete
garbage...

Could you do us a favour though (I'm on my knees), how about one example on
using any
of the term structure models along with calibration. I'm sure Sad must have
at least some sort of
rough test harness for this stuff. I'm itching to get my hands on it, but
too lazy to work it out.

Then again, I know you guys work for a living and thus may not have time.
Then again Saturday is a possibility...!!

By the way, full marks of the PDE stuff.
Eventually (my favorite word too!) your term structure models should be
applied to this stuff too.

Toy.

----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Tuesday, March 12, 2002 9:29 AM
Subject: Re: [Quantlib-users] Swaption Volatility...


> At 07:48 PM 3/11/02 +0000, Toyin Akin wrote:
> >Do you guys plan to model the whole Swaption Cube? (Exercise, Underlying
> >and Strike).
> >Or are you guys looking to model the smile in some sort of way?
> >
> >It seems like your current implementation handles only ATM Swaptions.
>
> As a matter of fact, it does.
> I don't think we'll go and try to model the smile for the time being. But
I
> think I'll put a hook there so that we can add the smile eventually
> ("eventually" seems to be a recurrent word in my replies lately, doesn't
it?)
>
> Bye,
>          Luigi
>

[Luigi Ballabio-4]

Hi,

At 8:15 PM +0000 3/12/02, Toyin Akin wrote:
>When you say "As a matter of fact, it does", do you mean that it does handle
>Strikes, underlying, option mat, or it does handle ATM vols only.

It was the latter. There's no strike info there.

>In addition, even though your class is called SwaptionVolatilityMatrix, it
>can easily handle cap/floor vols (or should that be caplet and
>floorlet vols), Basically underlyings less than one year.

True. But I rather had them separated for clarity.
For swaption volatilities we need a method

volatility(exerciseDate,length,strike);

for cap flat volatilities

volatility(endDate,tenor,strike)

in case we keep volatilities for different tenors in one object, or

volatility(endDate,strike)

if we use different instances for different tenors.
Finally, caplet volatilities would need

volatility(startDate,tenor,strike) or
volatility(startDate,strike)

It would not be that easy to create a single universal volatility
object whose volatility() method does different things depending on
the context.
But even if it were easy, I wouldn't do it. I very much prefer three
different classes for the above.

>I think it would be a shame if the strikes were omitted as a user can just
>construct your new vol object and then promtly forget about
>handling/generating them when pricing vanilla options.

This is the idea. Be patient.

>Could you do us a favour though (I'm on my knees), how about one example on
>using any of the term structure models along with calibration. I'm
>sure Sad must have at least some sort of rough test harness for this
>stuff. I'm itching to get my hands on it, but too lazy to work it
>out.

I'm sorry to break the news to you this way, but Sad is on a
well-deserved vacation right now...

>Then again, I know you guys work for a living and thus may not have time.
>Then again Saturday is a possibility...!!

Ok, _you_ tell my wife...

Bye,
        Luigi

--

[Ferdinando M. Ametrano-2]

>By the way, full marks of the PDE stuff.
>Eventually (my favorite word too!) your term structure models should be
>applied to this stuff too.
eventually? definitely? ;-)
unfortunately not in the 0.3.0 ;-)

ciao -- Nando

[Sadruddin Rejeb-3]

> Could you do us a favour though (I'm on my knees), how about one example
on
> using any
> of the term structure models along with calibration. I'm sure Sad must
have
> at least some sort of
> rough test harness for this stuff. I'm itching to get my hands on it, but
> too lazy to work it out.

Sorry, but I'm far, far away until the end of next week. However, I took my
laptop
with me and had the time to make a few enhancements to the code (thanks
Marco!)
and corrected a few horrible bugs. Moreover, I've made a simple example
showing how
to calibrate the models (both analytically and numerically) and to price a
Bermudan
swaption. This should qualify the term-structure modelling framework as
0.3.0 material.

> Eventually (my favorite word too!) your term structure models should be
> applied to this stuff too.
Yes, eventually. I'm currently working on it, but don't expect it to be
included in 0.3.0.

Regards,
Sad

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net