Re: [QuantLib-svn] SF.net SVN: quantlib: [12671] trunk/QuantLib

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib: [12671] trunk/QuantLib

Luigi Ballabio
On Mon, 2007-09-17 at 09:10 -0700, [hidden email] wrote:
> Log Message:
> -----------
> renamed capstripper2.*pp as optionletstripper.*pp

Is capstripper to be abandoned, or are they alternative? What's the
difference between the two?

Luigi


--

Weiler's Law:
Nothing is impossible for the man who doesn't have to
do it himself.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib: [12671] trunk/QuantLib

Ferdinando M. Ametrano-3
Hi Luigi
> > renamed capstripper2.*pp as optionletstripper.*pp
>
> Is capstripper to be abandoned, or are they alternative? What's the
> difference between the two?

yes capstripper will be abandoned as we move to better alternatives.
This evolution is tightly related to the work I'm doing on volatility
term structures. the idea is to design the abstract base classes in a
way which enforce more financial constraints depending on the asset
class (equity-fx or interest rate). The interest rate one should also
allow for at least two kind of market smiles, the one quoted as spread
over the atm strike and atm vol, and the one quoted at fixed strikes,
and we need facilities for abcd interpolation of the atm backbone, and
sabr interpolation of the smile. Hopefully in 3-4 weeks the job will
be completed.

In the meantime those interested might take a look at the new classes:
BlackAtmVolCurve (suitable for both equity-fx and interest rate, atm only)
---- AbcdAtmVolCurve  (suitable for interest rate, atm only)
---- BlackVolSurface (suitable for both equity-fx and interest rate, atm+smile)
-------- EquityFXVolSurface (suitable for equity-fx, atm+smile)
-------- InterestRateVolSurface (suitable for interest rate, atm+smile)
------------ SabrVolSurface (suitable for interest rate, atm+smile)

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib: [12671] trunk/QuantLib

Luigi Ballabio
On Tue, 2007-09-18 at 10:37 +0200, Ferdinando Ametrano wrote:

> yes capstripper will be abandoned as we move to better alternatives.
> This evolution is tightly related to the work I'm doing on volatility
> term structures. the idea is to design the abstract base classes in a
> way which enforce more financial constraints depending on the asset
> class (equity-fx or interest rate). The interest rate one should also
> allow for at least two kind of market smiles, the one quoted as spread
> over the atm strike and atm vol, and the one quoted at fixed strikes,
> and we need facilities for abcd interpolation of the atm backbone, and
> sabr interpolation of the smile. Hopefully in 3-4 weeks the job will
> be completed.
>
> In the meantime those interested might take a look at the new classes:
> BlackAtmVolCurve (suitable for both equity-fx and interest rate, atm only)
> ---- AbcdAtmVolCurve  (suitable for interest rate, atm only)
> ---- BlackVolSurface (suitable for both equity-fx and interest rate, atm+smile)
> -------- EquityFXVolSurface (suitable for equity-fx, atm+smile)
> -------- InterestRateVolSurface (suitable for interest rate, atm+smile)
> ------------ SabrVolSurface (suitable for interest rate, atm+smile)

Hmm. A few notes:

1) BlackVolSurface cannot inherit from BlackAtmVolCurve. The "is a"
relationship doesn't work. Well, at least the way I understand
them---see point 3).

2) at-the-money interpolation such as ABCD and smile interpolation such
as SABR are orthogonal choices (yes, I know that they are probably the
only sensible choices, but bear with me.) If you embed them in base
classes such as AbcdAtmVolCurve, you're going to end up with classes
such as AbcdAtmSabrVolSurface. On the one hand, they are going to
proliferate exponentially with the number of interpolations; and on the
other hand, you end up with diamond inheritance and all its problems.
Instead of coding them base classes, you'll be better off coding ABCD or
SABR as policies so that you can combine them freely. The same goes for
how to quote the smile---another orthogonal choice.

3) How about describing the design you have in mind so that we can
discuss it a bit on the list?

Later,
        Luigi


--

Prediction is very difficult, especially if it's about the future.
-- Niels Bohr



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev