quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] LocalvolSurface.cpp

[Michael H. <Mic...@gm...>]

Hallo Nando,



-----Original Message-----
On Mon, Apr 27, 2009 at 11:20 AM, Michael Heckl <Mic...@gm...>
wrote:
> I set up a constant extrapolation for both, Strike and
> Maturity in my BlackVarianceSurface.

I don't work on equities but constant variance extrapolation in strike
and maturity seems plain wrong to me. In time it implies zero forward
volatility, in strike it violates concavity smile requirement

ciao -- Nando

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


What is done with the time extrapolation is the following:

if (t<=times_.back())
            return varianceSurface_(t, strike, true);
else // t>times_.back() || extrapolate
           return varianceSurface_(times_.back(), strike, true) *
                t/times_.back();


I.e. the implied variance surface is not extrapolated constant in time, but
the implied volatility surface.

What exactly do you mean by zero forward volatility. IMHO the forward
volatility would be in that case (between two dates past at extrapolation)
exactly the constant extrapolated volatility (analog as with interest rates
for instance).


And at Strikes past the maximum/minimum Strike the implied variance surface
is indeed extrapolated flat, i.e. 


// enforce constant extrapolation when required
        if (strike < strikes_.front()
            && lowerExtrapolation_ == ConstantExtrapolation)
            strike = strikes_.front();
        if (strike > strikes_.back()
            && upperExtrapolation_ == ConstantExtrapolation)
            strike = strikes_.back();



Well, I don't know what you mean with your concavity smile requirement. But
I cant see what the problem should be with this extrapolation?

If you look at the No-Arbitrage requirements for the implied volatility
surface they only give limites to the slope.

But constant extrapolation means zero slope. So I cant see any restrictions
to that.

You can find no-arbitrage restrictions for the implied volatility for
instance at Roger W. Lee ("Implied Volatility: Statics, Dynamics, and
Probabalistic Interpretation")

The paper is online here:

http://www.math.uchicago.edu/~rl/



Can you send me a paper which works out the arguments you stated?


Greetings,
Michael

Re: [Quantlib-dev] LocalvolSurface.cpp

[Ferdinando A. <qf...@am...>]

On Mon, Apr 27, 2009 at 11:20 AM, Michael Heckl <Mic...@gm...> wrote:
> I set up a constant extrapolation for both, Strike and
> Maturity in my BlackVarianceSurface.

I don't work on equities but constant variance extrapolation in strike
and maturity seems plain wrong to me. In time it implies zero forward
volatility, in strike it violates concavity smile requirement

ciao -- Nando

Re: [Quantlib-dev] Bug#525603: libquantlib0-dev: quantlib-test-suite error

[Dirk E. <ed...@de...>]

On 27 April 2009 at 11:48, Ferdinando Ametrano wrote:
| Hi Dirk
| 
| the issue arises when the test is run on a non-trading day. To fix
| this I've added a
|             Settings::instance().evaluationDate() =
|                 conventions.calendar.adjust(Date::todaysDate());
| line so it won't happen again.

Cool, thank you!

Dirk

| thank you for the report
| 
| ciao -- Nando
| 
| On Sun, Apr 26, 2009 at 2:13 PM, Dirk Eddelbuettel <ed...@de...> wrote:
| >
| > Hi,
| >
| > Arnaud noticed that quantlib-test-suite dies on the error below, seemingly
| > from the code in test-suite/swaptionvolatilitymatrix.cpp that does:
| >
| >                    Date exerciseDate = swaption.exercise()->dates().front();
| >                    if (exerciseDate!=vol->optionDates()[i])
| >                        BOOST_FAIL(
| >                             "optionDateFromTenor mismatch for " <<
| >                             description << ":"
| >                             "\n      option tenor: " << atm.tenors.options[i] <<
| >                             "\nactual option date: " << exerciseDate <<
| >                             "\n  exp. option date: " << vol->optionDates()[i]);
| >
| >
| > This happened to him on amd64, I see the same on i386.  Is that considered an
| > actual bug, or merely an imperfect implementation in the date logic in
| > swaption exercise handling ?
| >
| > Thanks, Dirk
| >
| > On 25 April 2009 at 22:53, Arnaud Battistella wrote:
| > | Hi,
| > | This is probably a rather unimportant bug; however, quantlib-test-suite reports 1 failure. I do not know if
| > | this problem is old or not as it is the first time I run this command (I only use quantlib from R). Let me
| > | know if you need additional information.
| > | Thanks again for your amazing work with R, quantlib, gsl etc...
| > | Very best!
| > | A.
| > |
| > | Output:
| > |
| > | Running 390 test cases...
| > | swaptionvolatilitymatrix.cpp(214): fatal error in
| > | "SwaptionVolatilityMatrixTest::testSwaptionVolMatrixCoherence": optionDateFromTenor mismatch for floating
| > | reference date, floating market data:
| > |       option tenor: 1M
| > | actual option date: May 25th, 2009
| > |   exp. option date: May 27th, 2009
| > |
| > | Tests completed in 18 m 35 s
| > |
| > |
| > | *** 1 failure detected in test suite "Master Test Suite"
| > |
| > | -- System Information:
| > | Debian Release: squeeze/sid
| > |   APT prefers testing
| > |   APT policy: (990, 'testing'), (300, 'unstable')
| > | Architecture: amd64 (x86_64)
| > |
| > | Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
| > | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
| > | Shell: /bin/sh linked to /bin/bash
| > |
| > | Versions of packages libquantlib0-dev depends on:
| > | ii  libboost-test-dev           1.34.1-15+b1 components for writing and executi
| > | ii  libboost-test1.34.1         1.34.1-15+b1 components for writing and executi
| > | ii  libc6                       2.9-4        GNU C Library: Shared libraries
| > | ii  libc6-dev                   2.9-4        GNU C Library: Development Librari
| > | ii  libgcc1                     1:4.3.3-3    GCC support library
| > | ii  libquantlib-0.9.7           0.9.7-1      Quantitative Finance Library -- de
| > | ii  libstdc++6                  4.3.3-3      The GNU Standard C++ Library v3
| > |
| > | libquantlib0-dev recommends no packages.
| > |
| > | libquantlib0-dev suggests no packages.
| > |
| > | -- no debconf information
| > |
| > |
| >
| > --
| > Three out of two people have difficulties with fractions.
| >
| > ------------------------------------------------------------------------------
| > Crystal Reports &#45; New Free Runtime and 30 Day Trial
| > Check out the new simplified licensign option that enables unlimited
| > royalty&#45;free distribution of the report engine for externally facing
| > server and web deployment.
| > http://p.sf.net/sfu/businessobjects
| > _______________________________________________
| > QuantLib-dev mailing list
| > Qua...@li...
| > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| >

-- 
Three out of two people have difficulties with fractions.

Re: [Quantlib-dev] Adding new functions to blackcalculator

[Dima <dim...@go...>]

Thanks a lot. Did you have the chance to look at the black calculator that I
posted?
Sorry for annoying, but since I'm using it intensively in all of my current
classes I'm
just afraid that the discussion will start later and I have to go back and
change
everything in all of the classes :)


2009/4/27 Ferdinando Ametrano <na...@am...>

> On Mon, Apr 27, 2009 at 11:03 AM, Dima <dim...@go...>
> wrote:
> > While I'm still waiting for feedback
>
> I've just committed your fix for the (stdDev<QL_EPSILON, fwd==strike) case
>
> > I'd need smilesection.hpp to return the reference date. Is this possible?
> just done.
>
> > I continue coding and have VannaVolga and
> > Malz ready, testing included.
>
> share them as a patch whenever you're comfortable with them
>
> ciao -- Nando
>

Re: [Quantlib-dev] Adding new functions to blackcalculator

[Ferdinando A. <na...@am...>]

On Mon, Apr 27, 2009 at 11:03 AM, Dima <dim...@go...> wrote:
> While I'm still waiting for feedback

I've just committed your fix for the (stdDev<QL_EPSILON, fwd==strike) case

> I'd need smilesection.hpp to return the reference date. Is this possible?
just done.

> I continue coding and have VannaVolga and
> Malz ready, testing included.

share them as a patch whenever you're comfortable with them

ciao -- Nando

Re: [Quantlib-dev] Bug#525603: libquantlib0-dev: quantlib-test-suite error

[Ferdinando A. <qf...@am...>]

Hi Dirk

the issue arises when the test is run on a non-trading day. To fix
this I've added a
            Settings::instance().evaluationDate() =
                conventions.calendar.adjust(Date::todaysDate());
line so it won't happen again.

thank you for the report

ciao -- Nando

On Sun, Apr 26, 2009 at 2:13 PM, Dirk Eddelbuettel <ed...@de...> wrote:
>
> Hi,
>
> Arnaud noticed that quantlib-test-suite dies on the error below, seemingly
> from the code in test-suite/swaptionvolatilitymatrix.cpp that does:
>
>                    Date exerciseDate = swaption.exercise()->dates().front();
>                    if (exerciseDate!=vol->optionDates()[i])
>                        BOOST_FAIL(
>                             "optionDateFromTenor mismatch for " <<
>                             description << ":"
>                             "\n      option tenor: " << atm.tenors.options[i] <<
>                             "\nactual option date: " << exerciseDate <<
>                             "\n  exp. option date: " << vol->optionDates()[i]);
>
>
> This happened to him on amd64, I see the same on i386.  Is that considered an
> actual bug, or merely an imperfect implementation in the date logic in
> swaption exercise handling ?
>
> Thanks, Dirk
>
> On 25 April 2009 at 22:53, Arnaud Battistella wrote:
> | Hi,
> | This is probably a rather unimportant bug; however, quantlib-test-suite reports 1 failure. I do not know if
> | this problem is old or not as it is the first time I run this command (I only use quantlib from R). Let me
> | know if you need additional information.
> | Thanks again for your amazing work with R, quantlib, gsl etc...
> | Very best!
> | A.
> |
> | Output:
> |
> | Running 390 test cases...
> | swaptionvolatilitymatrix.cpp(214): fatal error in
> | "SwaptionVolatilityMatrixTest::testSwaptionVolMatrixCoherence": optionDateFromTenor mismatch for floating
> | reference date, floating market data:
> |       option tenor: 1M
> | actual option date: May 25th, 2009
> |   exp. option date: May 27th, 2009
> |
> | Tests completed in 18 m 35 s
> |
> |
> | *** 1 failure detected in test suite "Master Test Suite"
> |
> | -- System Information:
> | Debian Release: squeeze/sid
> |   APT prefers testing
> |   APT policy: (990, 'testing'), (300, 'unstable')
> | Architecture: amd64 (x86_64)
> |
> | Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
> | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> | Shell: /bin/sh linked to /bin/bash
> |
> | Versions of packages libquantlib0-dev depends on:
> | ii  libboost-test-dev           1.34.1-15+b1 components for writing and executi
> | ii  libboost-test1.34.1         1.34.1-15+b1 components for writing and executi
> | ii  libc6                       2.9-4        GNU C Library: Shared libraries
> | ii  libc6-dev                   2.9-4        GNU C Library: Development Librari
> | ii  libgcc1                     1:4.3.3-3    GCC support library
> | ii  libquantlib-0.9.7           0.9.7-1      Quantitative Finance Library -- de
> | ii  libstdc++6                  4.3.3-3      The GNU Standard C++ Library v3
> |
> | libquantlib0-dev recommends no packages.
> |
> | libquantlib0-dev suggests no packages.
> |
> | -- no debconf information
> |
> |
>
> --
> Three out of two people have difficulties with fractions.
>
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] LocalvolSurface.cpp

[Michael H. <Mic...@gm...>]

Hallo Klaus,

I ran my tests with both. BiLinear and BiCubic intrapolation. I encountered
the instability issues with both.

You are right that the problems appear far ITM and OTM. But I cant really
figure out why, since I set up a constant extrapolation for both, Strike and
Maturity in my BlackVarianceSurface.

I attached the cpp file that I use for my tests as well as a small jpg of
the surface that is included in my test cases.

I hope this gives you all the information you need and you can give me some
feedback on my test cases.

Thank you also for the link. To me it seem like if we want to use the dupire
formula efficient, stable and productive, we wont get around implementing
some fancy optimization-splines and smoothing algorithm.

I am looking forward to hear back from you.

Greetings,
Michael



-----Original Message-----
From: Klaus Spanderen [mailto:kl...@sp...] 
Sent: Sonntag, 26. April 2009 22:01
To: qua...@li...
Cc: Michael Heckl
Subject: Re: [Quantlib-dev] LocalvolSurface.cpp

>
> It happens at different strikes and moneyness under some conditions that
> the d2wdy2 blows up and becomes something like -4231,12
>

Which interpolation scheme do you use for the volatility surface. The
standard 
interpolation is linear in the variance which very often leads to problems 
with the second derivative. Therefore I've used BicubicSplineInterpolation

    volTS->setInterpolation<Bicubic>();

 
Does this happen only for deep ITM or OTM paths? (Is this a extrapolation 
problem for very large (very small) spots?) At least for "extrem" 
extrapolations" I found simillar problems and "solved" it be setting
negative 
variances to zero. 

Can I get access to the parameters of your test-surface?

> But would that probably 
> make the dupire formula useless to us?

People your using e.g. splines together with an optimization technique like
in

Reconstructing The Unknown Local Volatility Function, Thomas F. Coleman, 
Yuying Li, ARUN VERMA, 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.6202

to solve the instability. But a lot of code is needed to implemented
this;-(. 
For the time being I think we should give Nando's approach a try and use the

first and second derivatives taken from the interpolation method


regards 
 Klaus

Re: [Quantlib-dev] LocalvolSurface.cpp

[Klaus S. <kl...@sp...>]

Hi Micheal

> First of all I found some minor errors in your code which are:

yes, you are obviously right. I've changed the code in the SVN repository 
accordingly. Thanks for the hint!

>
> It happens at different strikes and moneyness under some conditions that
> the d2wdy2 blows up and becomes something like -4231,12
>

Which interpolation scheme do you use for the volatility surface. The standard 
interpolation is linear in the variance which very often leads to problems 
with the second derivative. Therefore I've used BicubicSplineInterpolation

    volTS->setInterpolation<Bicubic>();

 
Does this happen only for deep ITM or OTM paths? (Is this a extrapolation 
problem for very large (very small) spots?) At least for "extrem" 
extrapolations" I found simillar problems and "solved" it be setting negative 
variances to zero. 

Can I get access to the parameters of your test-surface?

> For some reason I don't get rid of the feeling that we would be better of
> to work completely without the second derivative since it seems to be
> impossible to get this numerically under control. 

No, IMO the second derivative is needed.

> But would that probably 
> make the dupire formula useless to us?

People your using e.g. splines together with an optimization technique like in

Reconstructing The Unknown Local Volatility Function, Thomas F. Coleman, 
Yuying Li, ARUN VERMA, 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.6202

to solve the instability. But a lot of code is needed to implemented this;-(. 
For the time being I think we should give Nando's approach a try and use the 
first and second derivatives taken from the interpolation method


regards 
 Klaus

Re: [Quantlib-dev] Bug#525603: libquantlib0-dev: quantlib-test-suite error

[Dirk E. <ed...@de...>]

Hi,

Arnaud noticed that quantlib-test-suite dies on the error below, seemingly
from the code in test-suite/swaptionvolatilitymatrix.cpp that does:

                    Date exerciseDate = swaption.exercise()->dates().front();
                    if (exerciseDate!=vol->optionDates()[i])
                        BOOST_FAIL(
                             "optionDateFromTenor mismatch for " <<
                             description << ":"
                             "\n      option tenor: " << atm.tenors.options[i] <<
                             "\nactual option date: " << exerciseDate <<
                             "\n  exp. option date: " << vol->optionDates()[i]);


This happened to him on amd64, I see the same on i386.  Is that considered an
actual bug, or merely an imperfect implementation in the date logic in
swaption exercise handling ?

Thanks, Dirk

On 25 April 2009 at 22:53, Arnaud Battistella wrote:
| Hi,
| This is probably a rather unimportant bug; however, quantlib-test-suite reports 1 failure. I do not know if 
| this problem is old or not as it is the first time I run this command (I only use quantlib from R). Let me 
| know if you need additional information.
| Thanks again for your amazing work with R, quantlib, gsl etc...
| Very best!
| A.
| 
| Output:
| 
| Running 390 test cases...
| swaptionvolatilitymatrix.cpp(214): fatal error in 
| "SwaptionVolatilityMatrixTest::testSwaptionVolMatrixCoherence": optionDateFromTenor mismatch for floating 
| reference date, floating market data:
|       option tenor: 1M
| actual option date: May 25th, 2009
|   exp. option date: May 27th, 2009
| 
| Tests completed in 18 m 35 s
| 
| 
| *** 1 failure detected in test suite "Master Test Suite"
| 
| -- System Information:
| Debian Release: squeeze/sid
|   APT prefers testing
|   APT policy: (990, 'testing'), (300, 'unstable')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
| Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/bash
| 
| Versions of packages libquantlib0-dev depends on:
| ii  libboost-test-dev           1.34.1-15+b1 components for writing and executi
| ii  libboost-test1.34.1         1.34.1-15+b1 components for writing and executi
| ii  libc6                       2.9-4        GNU C Library: Shared libraries
| ii  libc6-dev                   2.9-4        GNU C Library: Development Librari
| ii  libgcc1                     1:4.3.3-3    GCC support library
| ii  libquantlib-0.9.7           0.9.7-1      Quantitative Finance Library -- de
| ii  libstdc++6                  4.3.3-3      The GNU Standard C++ Library v3
| 
| libquantlib0-dev recommends no packages.
| 
| libquantlib0-dev suggests no packages.
| 
| -- no debconf information
| 
| 

-- 
Three out of two people have difficulties with fractions.

Re: [Quantlib-dev] LocalvolSurface.cpp

[Michael H. <Mic...@gm...>]

Hallo Klaus,

I checked out your new version of the localvolsurface.cpp from the SVN and
run some extensive tests.

First of all I found some minor errors in your code which are:

1. (Line 116): Real strikept = strike*dr*dq/(drpt*dqpt);
This should be:
	Real strikept = strike*dr*dqpt/(drpt*dq);

2. (same in line 130 and 131):
	Real strikept = strike*dr*dq/(drpt*dqpt);
	Real strikemt = strike*dr*dq/(drmt*dqmt);
This should be:
	Real strikept = strike*dr*dqpt/(drpt*dq);
	Real strikemt = strike*dr*dqmt/(drmt*dq);


Just minor things, but think it over. You divide through the risk free
discount and multiply with the dividend discount. And if you do this from t
to t+dt then this is what you get.


Now a few words what I figured out by extensive testing. I ran tests with MC
with 100 thousand of paths. And your Bug-Fix brought some slight
improvements but the problem with the second derivative still remains.

It happens very often that the program crashes and tells me "negative local
vol^2 at ..."

The black vol surface I am using is very smooth. So this is not the reason
for the problems. Much more is the problem again the numerical instability
when taking the second derivative of the implied variance surface with
respect to the log-moneyness.

Let me introduce 2 more variables:

Real z1,z2;

Where

z1=wp-wm;

z2=wp-2.0*w+wm;


Then the first derivative of w with respect to log-moneyness is:

dwdy = (z1)/(2.0*dy);

And the second is:

d2wdy2 = (z2)/(dy*dy);


It happens at different strikes and moneyness under some conditions that the
d2wdy2 blows up and becomes something like -4231,12

Like a really big negative number. This obviously makes the denominator
which consists of  den1+den2+den3  negative and the whole program crashes.

The numerator is always positive since we make sure that the implied
variance is monotone increasing.

So the only thing we have to take care about is that our denominator is not
getting negative.

I figured out (by extensive testing and only empirically) that 

0.4 < den1+den2<1.3

So at least for the surfaces I was testing, this was always given. So
basically we have to make sure that den3 is not getting smaller then -0.4 in
order for the program not to crash.

But my tests showed that den3 is either in the green zone or it blows up
dramatically which gives me the suppression that we encounter some numerical
problems under certain conditions.

The only way how I managed for the program to run stable is by controlling
z1,z2 by setting:

if ((std::abs(z1) < std::abs(dy)/1000 && z1!=0.0) || std::abs(z1) >
2*std::abs(dy)) 
			z1=0;

and


if ((std::abs(z2) < dy*dy/1000 && z2!=0.0) || std::abs(z2) > dy*dy) 
			z2=0;


So what I basically do is setting the first derivative to zero when it is
getting so small that it doesn't really affect our result anymore anyways.
Same with the second derivative.

But the more critical part is setting the derivative to zero when it blows
up. I just cut off all critical values.

This makes (obviously) the program run stable.

On the off-side I cant really say for sure (at least till now) how big the
impacts of this manipulation are for the precision of our results. I figured
that we basically never get problems with z1 which means with the first
derivative. But we set the second derivative which means z2 quit often to
zero when it falls out of the good range.

For some reason I don't get rid of the feeling that we would be better of to
work completely without the second derivative since it seems to be
impossible to get this numerically under control. But would that probably
make the dupire formula useless to us?

Do you have any Ideas? Or can I help you with this issue any further?

Greetings,
Michael


PS: is it possible to write a paper which examines under which conditions
(what range for what variables and what interdependencies of the variables
and what restrictions to the shape of the black vol surface) the formula is
theoretically/mathematically possible (i.e. doesn't get negative) and then
use this new gained knowledge to make our code stable with the smallest
impact possible to the precision of the result?



-----Original Message-----
From: Klaus Spanderen [mailto:kl...@sp...] 
Sent: Freitag, 24. April 2009 00:07
To: qua...@li...
Cc: Michael Heckl; Ferdinando Ametrano
Subject: Re: [Quantlib-dev] LocalvolSurface.cpp

Hi Michael,

you wrote
> To be a bit more precise  the problem lies in the second derivative of the
> black variance with respect to the strike. Even if I take surfaces without
> Smile/Skew, i.e. flat ones, I still get the problem there. This is because
> (wp-2.0*w+wm) is not exactly zero but very very small. And this gets
> devided by 0. 000000000001.

To me the root of the problem was the line 

	dy = ((y!=0.0) ? y*0.000001 : 0.000001);

For ve y small y this code leads to unrealistic small dy and to numerical 
problems during the calculation of the difference quotient. Therfore I've 
changed it into 

	dy = ((std::fabs(y) > 0.001) ? y*0.0001 : 0.000001);

and at least for my tests the numerical problems with the difference
quotient 
disappeared. (pls see the latest version of localvolsurface.cpp in the SVN 
repository). Could you test this fix using your test cases? 

regards
 Klaus

Re: [Quantlib-dev] LocalvolSurface.cpp

[Klaus S. <kl...@sp...>]

Hi Michael,

you wrote
> To be a bit more precise  the problem lies in the second derivative of the
> black variance with respect to the strike. Even if I take surfaces without
> Smile/Skew, i.e. flat ones, I still get the problem there. This is because
> (wp-2.0*w+wm) is not exactly zero but very very small. And this gets
> devided by 0. 000000000001.

To me the root of the problem was the line 

	dy = ((y!=0.0) ? y*0.000001 : 0.000001);

For ve y small y this code leads to unrealistic small dy and to numerical 
problems during the calculation of the difference quotient. Therfore I've 
changed it into 

	dy = ((std::fabs(y) > 0.001) ? y*0.0001 : 0.000001);

and at least for my tests the numerical problems with the difference quotient 
disappeared. (pls see the latest version of localvolsurface.cpp in the SVN 
repository). Could you test this fix using your test cases? 

regards
 Klaus

Re: [Quantlib-dev] LocalvolSurface.cpp

[Ferdinando A. <qf...@am...>]

Hi Michael

> i recently did a lot of testing with the localvolSurface class (which
> contains Gatherals Dupire Formula) and i am not very happy with the results.
> Ok, the class is (regarding to the documentation) untested, so I guess I
> cant expect it to work properly.

Last week Klaus fixed time derivative (now performed at constant
moneyness instead of constant strike) and added tests.

> But I figured that numerical problems cause
> this class to return the error message “negative local vol …  the black vol
> surface is not smooth enough”. [...]
> the problem lies in the second derivative of the
> black variance with respect to the strike.

you are right. I will fix it, probably moving time/strike (numerical)
derivatives in the BlackVolTermStructure base interface, allowing for
overloading in derived classes which might provide exact derivatives.

BTW I have a related question. Black ATM variance must be increasing
in time; I've always taken for granted that this is also true for
every (not just ATM) constant moneyness section of the Black surface.
Is this a non-arbitrage result or shaky common sense?

ciao -- Nando

[Quantlib-dev] LocalvolSurface.cpp

[Michael H. <Mic...@gm...>]

Hello everybody,

 

i recently did a lot of testing with the localvolSurface class (which
contains Gatherals Dupire Formula) and i am not very happy with the results.
Ok, the class is (regarding to the documentation) untested, so I guess I
cant expect it to work properly. But I figured that numerical problems cause
this class to return the error message "negative local vol .  the black vol
surface is not smooth enough". This also happens for very smooth black vol
surfaces. The Problem lies in this code:

 

 

 

 

 

Real forwardValue = underlying *

            (dividendTS->discount(t, true)/

             riskFreeTS->discount(t, true));

 

        // strike derivatives

        Real strike, y, dy, strikep, strikem;

        Real w, wp, wm, dwdy, d2wdy2;

        strike = underlyingLevel;

        y = std::log(strike/forwardValue);

        dy = ((y!=0.0) ? y*0.000001 : 0.000001);

        strikep=strike*std::exp(dy);

        strikem=strike/std::exp(dy);

        w  = blackTS->blackVariance(t, strike,  true);

        wp = blackTS->blackVariance(t, strikep, true);

        wm = blackTS->blackVariance(t, strikem, true);

        dwdy = (wp-wm)/(2.0*dy);

        d2wdy2 = (wp-2.0*w+wm)/(dy*dy);

 

        // time derivative

        Real dt, wpt, wmt, dwdt;

        if (t==0.0) {

            dt = 0.0001;

            wpt = blackTS->blackVariance(t+dt, strike, true);

            QL_ENSURE(wpt>=w,

                      "decreasing variance at strike " << strike

                      << " between time " << t << " and time " << t+dt);

            dwdt = (wpt-w)/dt;

        } else {

            dt = std::min<Time>(0.0001, t/2.0);

            wpt = blackTS->blackVariance(t+dt, strike, true);

            wmt = blackTS->blackVariance(t-dt, strike, true);

            QL_ENSURE(wpt>=w,

                      "decreasing variance at strike " << strike

                      << " between time " << t << " and time " << t+dt);

            QL_ENSURE(w>=wmt,

                      "decreasing variance at strike " << strike

                      << " between time " << t-dt << " and time " << t);

            dwdt = (wpt-wmt)/(2.0*dt);

        }

 

        if (dwdy==0.0 && d2wdy2==0.0) { // avoid /w where w might be 0.0

            return std::sqrt(dwdt);

        } else {

            Real den1 = 1.0 - y/w*dwdy;

            Real den2 = 0.25*(-0.25 - 1.0/w + y*y/w/w)*dwdy*dwdy;

            Real den3 = 0.5*d2wdy2;

            Real den = den1+den2+den3;

            Real result = dwdt / den;

            QL_ENSURE(result>=0.0,

                      "negative local vol^2 at strike " << strike

                      << " and time " << t

                      << "; the black vol surface is not smooth enough");

            return std::sqrt(result);

            // return std::sqrt(dwdt / (1.0 - y/w*dwdy +

            //    0.25*(-0.25 - 1.0/w + y*y/w/w)*dwdy*dwdy + 0.5*d2wdy2));

        }

 

 

 

 

To be a bit more precise  the problem lies in the second derivative of the
black variance with respect to the strike. Even if I take surfaces without
Smile/Skew, i.e. flat ones, I still get the problem there. This is because
(wp-2.0*w+wm) is not exactly zero but very very small. And this gets devided
by 0. 000000000001. So if it is not exactly zero but very very little
negative, it can blow up the whole calculations and we end up with this
error message. To avoid these numerical problems I now decreased the
accuracy in the derivatives a little bit and also introduced a check that
sets this term to zero if it is very very very small (smaller than 1.0e-12).
Furthermore I changed the derivative with respect to the time. This was not
necessary but I wanted to make it equal to the localvolcurve.cpp code which
works just fine. The modified code now looks like:

 

 

 

 

 

Real forwardValue = underlying *

          (dividendTS->discount(t, true)/

           riskFreeTS->discount(t, true));

 

 

        // strike derivatives

        Real strike, y, dy, strikep, strikem;

        Real w, wp, wm, dwdy, d2wdy2;

            Real z1,z2;

        

            // strike ist gegeben

            strike = underlyingLevel;

        

            // log(strike/forwardValue)

            y = std::log(strike/forwardValue);

            std::cout << "y: "    << y << std::endl;

        

            // wir leiten blackScholesVariance nach y ab, bilde daher
diskrete kleine unterteilung

            dy = ((y!=0.0) ? y*0.0001 : 0.0001);

            std::cout << "dy: "    << dy << std::endl;

 

 

        strikep=strike*std::exp(dy);

        strikem=strike/std::exp(dy);

        w  = blackTS->blackVariance(t, strike,  true);

        wp = blackTS->blackVariance(t, strikep, true);

        wm = blackTS->blackVariance(t, strikem, true);

        z1=wp-wm;

            if (std::abs(z1) < 1.0e-12)

                  z1=0;

        dwdy = (z1)/(2.0*dy);

        z2=wp-2.0*w+wm;

        if (std::abs(z2) < 1.0e-12)

                  z2=0;

        d2wdy2 = (z2)/(dy*dy);

            

            

 

 

        // time derivative

        Real dt, wpt, wmt, dwdt;

 

            dt = (1.0/365.0);

        wpt = blackTS->blackVariance(t+dt, strike, true);

            QL_ENSURE(wpt>=w,

                      "decreasing variance at strike " << strike

                      << " between time " << t << " and time " << t+dt);

        dwdt = (wpt-w)/dt;

        

 

        if (dwdy==0.0 && d2wdy2==0.0) { // avoid /w where w might be 0.0

            return std::sqrt(dwdt);

        } else {

            Real den1 = 1.0 - y/w*dwdy;

            Real den2 = 0.25*(-0.25 - 1.0/w + y*y/w/w)*dwdy*dwdy;

            Real den3 = 0.5*d2wdy2;

            Real den = den1+den2+den3;

            Real result = dwdt / den;

            QL_ENSURE(result>=0.0,

                      "negative local vol^2 at strike " << strike

                      << " and time " << t

                      << "; the black vol surface is not smooth enough");

            return std::sqrt(result);

            // return std::sqrt(dwdt / (1.0 - y/w*dwdy +

            //    0.25*(-0.25 - 1.0/w + y*y/w/w)*dwdy*dwdy + 0.5*d2wdy2));

        }

 

 

 

 

So far all the testing I did I received much better and more stable results.
But since I am not an expert in computational and numerical methods
regarding precision, can anybody who is a bit more experienced with c++
numerical issues give me some advice and probably check this out?

 

 

Greetings

Michael

Re: [Quantlib-dev] Heston.cpp Alan Lewis decorrelation for Heston

[Klaus S. <kl...@sp...>]

Hi

> In Hestonprocess.cpp there is a switch on Exact Variance Simulation where
> it's said that one uses Alan Lewi's trick to decorrelate equity and
> variance process.


If the equity process and the variance process are not correlated in the 
Heston model one can use an exact sampling method for the variance process, 
which is a "square root" process. (see e.g. Glasserman, Monte Carlo Methods 
in Finance). This removes one main source for the bias of Monte-Carlo 
Sampling methods for the Heston model, namely the variance process can not 
get negative values using this discretization method. 

To achieve zero correlation for a "normal" Heston model one should transform 
the equity process x(t)=ln(S(t)) using Ito's Lemma and 

y(t)=x(t)-\frac{rho}{sigma}\nu(t). 

This removes the correlation between y(t) and the variance and one can use 
exact sampling for the variance process and Euler discretization for y(t). 

This schema might be better than the other discretization schemes if \sigma is 
large.

regards

 Klaus

Re: [Quantlib-dev] Confronting the upfront

[Jose Aparicio-N. <ja...@fr...>]

Quoting Ferdinando Ametrano <qf...@am...>:

> I wonder how to bootstrap including an upfront if depending on the
> TermStructure reference date the upfront might not enter the NPV?
>
> ;-)
>
> ok, ok, I'm joking... sorry... I just couldn't resist... :-D
>
> ciao -- Nando
>

Its not sci fiction, its in there:
and it boostraps from it

    void MidPointCdsEngine::calculate() const {
[.....]
        // Upfront Flow NPV. Either we are on-the-run (no flow)
        // or we are forward start
        Real upfPVO1 = 0.0;
        if(!arguments_.upfrontPayment.hasOccurred(settlementDate, true))//true?
            upfPVO1 =
                probability_->survivalProbability(settlementDate) *
                discountCurve_->discount(settlementDate);
        results_.upfrontNPV = upfPVO1 * arguments_.upfrontPayment.amount();
[.....]

"hasOcurred" hits back...
Settlement lags are relevant here indeed (ordering combinations of
T_settle=upfrtPay  Today and T_protection_start), I did not enter the discussion
but followed with interest because of this but yes the meaning of today is
relevant.

Regards
Pepe

Re: [Quantlib-dev] Confronting the upfront

[Jose Aparicio-N. <ja...@fr...>]

Quoting Luigi Ballabio <lui...@gm...>:
> Yes. I was waiting for you to implement the changes you discussed with
> Roland. Not that I want to hurry you, of course...
>
Is there a QuantLib Union?
:-)

Now seriously, no less than a week to start discussing what I propose.

Regards
Pepe

Re: [Quantlib-dev] Confronting the upfront

[Ferdinando A. <qf...@am...>]

On Mon, Apr 20, 2009 at 11:56 PM, kevinwang <kev...@gm...> wrote:
> will this new upfront feature for CDS be in prodution soon?

I wonder how to bootstrap including an upfront if depending on the
TermStructure reference date the upfront might not enter the NPV?

;-)

ok, ok, I'm joking... sorry... I just couldn't resist... :-D

ciao -- Nando

Re: [Quantlib-dev] todaysDate in localtime ?

[Dirk E. <ed...@de...>]

On 21 April 2009 at 14:20, Luigi Ballabio wrote:
| On Mon, 2009-04-20 at 18:24 +0200, Ferdinando Ametrano wrote:
| > > We should probably use localtime as the default.
| > > Objections?
| > 
| > I agree
| 
| Done.

Perfect. I actually did the same in quick local copy of the function.
localtime() does make more sense.

Dirk

-- 
Three out of two people have difficulties with fractions.

Re: [Quantlib-dev] todaysDate in localtime ?

[Luigi B. <lui...@gm...>]

On Mon, 2009-04-20 at 18:24 +0200, Ferdinando Ametrano wrote:
> > We should probably use localtime as the default.
> > Objections?
> 
> I agree

Done.

Luigi


-- 

Perfection is reached, not when there is no longer anything to add, but 
when there is no longer anything to take away. 
-- Antoine de Saint-Exupery 

Re: [Quantlib-dev] Confronting the upfront

[Luigi B. <lui...@gm...>]

On Tue, 2009-04-21 at 12:17 +0200, Jose Aparicio-Navarro wrote:
> Probably yes (Luigi?).  

Yes. I was waiting for you to implement the changes you discussed with
Roland. Not that I want to hurry you, of course...

Luigi


-- 

Greenspun's Tenth Rule of Programming: 
Any sufficiently complicated C or Fortran program contains an 
ad-hoc, informally-specified bug-ridden slow implementation of 
half of Common Lisp. 

Re: [Quantlib-dev] Confronting the upfront

[Jose Aparicio-N. <ja...@fr...>]

Hi Kevin,
Probably yes (Luigi?).  The problem is that several data structures in the
credit framework need refactoring. I am currently working on it but its
taking me more trouble than I expected and I found less time for it than I
 thought.
I am not far from proposing something but it still needs to go to the
collaborative stage and get feedback from the other people involved. It
impacts all the credit side.
So even if you patch the code with the files I have submitted you might find
quite a different interface in the end.
Knowing that, if you want to test what it was submitted and provide feedback
that would be quite useful at this stage.
Regards
Pepe

Quoting kevinwang <kev...@gm...>:

>
> Hi, Pepe and Luigi, will this new upfront feature for CDS be in prodution
> soon?
>
> Thanks
> Kevin
>
>
> Jose Aparicio-Navarro wrote:
> >
> > Hello again,
> > my drive is quite a mess with so many versions of the lib and two of the
> > files I
> > have send you are the wrong ones. Please substitute them by these (for the
> > new
> > interface case).
> >
> > Apologies
> > Pepe
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> > CA
> > -OSBC tackles the biggest issue in open source: Open Sourcing the
> > Enterprise
> > -Strategies to boost innovation and cut costs with open source
> > participation
> > -Receive a $600 discount off the registration fee with the source code:
> > SFAD
> > http://p.sf.net/sfu/XcvMzF8H
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Confronting-the-upfront-tp22324891p23145719.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] EnhancedBlackScholesProcess which supports Vega Tests

[Luigi B. <lui...@gm...>]

On Thu, 2009-04-09 at 23:45 +0200, Michael Heckl wrote:
> I solved this problem by building up an Enhanced Black Scholes Process
> which takes as parameters a stress level and a square of the local
> Volatility Surface which it stresses on demand. I thought maybe anyone
> is interested in my solution? I already tested it and it works fine.
> The solution itself is quite easy and I am working with it so far
> without any problems. I would like to contribute it and maybe we can
> together improve it and enhance Quantlib?
> 
> Since this is my first experience with Quantlib Mailing Lists I am not
> quite sure if I can attach my cpp files? Can anybody give me some
> advice?

Sorry for the delay---yes, you can post them here or in the Sourceforge
patch manager.

Luigi


-- 

Just remember what ol' Jack Burton does when the earth quakes, the 
poison arrows fall from the sky, and the pillars of Heaven shake. Yeah, 
Jack Burton just looks that big old storm right in the eye and says, 
"Give me your best shot. I can take it." 
-- Jack Burton, "Big trouble in Little China" 

Re: [Quantlib-dev] libboost_filesystem-vc90-mt-sgd-1_38.lib

[Luigi B. <lui...@gm...>]

On Mon, 2009-04-20 at 14:19 -0700, artella wrote:
> I have downloaded boost 1.38 and built via bjam. When I try to build
> QuantLibXL_full_vc9.sln requests are made for :
> 
> 1)libboost_regex-vc90-mt-sgd-1_38.lib
> 2)libboost_serialization-vc90-mt-sgd-1_38.lib
> 3)libboost_unit_test_framework-vc90-mt-sgd-1_38.lib
> 
> I am able to find these. However a request is also made for : 
> 
> (-->libboost_filesystem-vc90-mt-sgd-1_38.lib<--)
> 
> which I have not managed to find. 

You have to run bjam with the "--build-type=complete" flag.

Luigi


-- 

Harrison's Postulate: 
For every action, there is an equal and opposite criticism. 

[Quantlib-dev] need volatility formula

[Ramesh P. <ram...@3i...>]

 

 

Hello,

 

 Iam a new quantlib user.Please excuse me for my navie question.

I want to implement volatility rate between different times like 1 week, 2
weeks, 3 weeks, 1 month...in any options like European, American.

I have some predefined inputs which are hard coded values. We need to
implement volatility. Please give me guidance to implement volatility.

Awaiting for your reply.

 

Thanks in Advance

Ramesh. 

 

 

 

 

 



---
This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient.If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and  associated companies, (collectively "3i Infotech"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects.

Re: [Quantlib-dev] Confronting the upfront

[kevinwang <kev...@gm...>]

Hi, Pepe and Luigi, will this new upfront feature for CDS be in prodution
soon? 

Thanks
Kevin


Jose Aparicio-Navarro wrote:
> 
> Hello again,
> my drive is quite a mess with so many versions of the lib and two of the
> files I
> have send you are the wrong ones. Please substitute them by these (for the
> new
> interface case).
> 
> Apologies
> Pepe
> 
>  
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/Confronting-the-upfront-tp22324891p23145719.html
Sent from the quantlib-dev mailing list archive at Nabble.com.