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 |
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 |
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 |
Free forum by Nabble | Edit this page |