curve generation issues

[JURAJ HUSKA]

Hello all,

this is an issue I ran into today (October 31, the dates seems to be important). I constructed "ExtendedDiscountCurve" with  yearly points going out to 30 years, with reference date = October 31, dayCounter = Thirty360 and businessDayConvention = ModifiedFollowing.

With these inputs I would get run time error, which I found turned out to be generated from "interpolation.hpp" file when QuantLib was performing "QL_EXTRA_SAFETY_CHECKS". I think I found the cause of these problems but some issues remain. Bottom line is: when dates and times are interpolated, the choice of dayCounter causes some dates to have  equal times ( e.g., 10/30/2009 and 10/31/2009 both have times = 2.0), which in turn causes run-time error when extra safety checks are performed. Interestingly, when businessDayConvention is changed to "Unadjusted" the error disappears.

When QuantLib is run in release mode, the extra checks are turned off. However, even then I ran a function (pricing some bonds) which blew up and after adjusting the businessDayConvention it ran just fine, I don't know where the error came from in this case... and would like to know.

Is it possible that a curve with a valid set of dates/discount factors (e.g., spaced from each other by yearly gaps) can blow up at run time even in release mode? (this would seem a bug to me)

Juraj

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Frank Hövermann]

Hi there!

When I change the value which is passed to .withTimeSteps starting from 1 to, say, 5 in the case of non-flat vol term structure (but flat skew) which is defined by 5 points on the time scale, the value 1 results in a plain vanilla call option's value which corresponds to the start vol (all else being equal). Increasing the number of time steps the option's value seems to approach the value of the closed form solution where the speed of convergence depends on the particular shape of the term structure in the neighborhood of maturity.

 

I would expect, especially in the case of one time step for this plain vanilla call, the vol to be taken as the terminal vol not the initial one. Am I wrong?

 

Regards

Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2007-10-31 at 17:22 -0500, JURAJ HUSKA wrote:

> this is an issue I ran into today (October 31, the dates seems to be
> important). I constructed "ExtendedDiscountCurve" with  yearly points
> going out to 30 years, with reference date = October 31, dayCounter =
> Thirty360 and businessDayConvention = ModifiedFollowing.
>
> With these inputs I would get run time error, which I found turned out
> to be generated from "interpolation.hpp" file when QuantLib was
> performing "QL_EXTRA_SAFETY_CHECKS". I think I found the cause of
> these problems but some issues remain. Bottom line is: when dates and
> times are interpolated, the choice of dayCounter causes some dates to
> have  equal times ( e.g., 10/30/2009 and 10/31/2009 both have times =
> 2.0), which in turn causes run-time error when extra safety checks are
> performed. Interestingly, when businessDayConvention is changed to
> "Unadjusted" the error disappears.

It might be caused both by the day counter and the fact that depending
on the business-day convention, different dates can be adjusted to the
same business day, thus becoming the same. Strange that yearly-spaced
points try to insert such values in the interpolation, though. Maybe
some special ExtendedDiscountCurve thing... (by the way,
ExtendedDiscountCurve will be deprecated. Use DiscountCurve instead.)

> When QuantLib is run in release mode, the extra checks are turned off.
> However, even then I ran a function (pricing some bonds) which blew up
> and after adjusting the businessDayConvention it ran just fine, I
> don't know where the error came from in this case... and would like to
> know.

The error is the same---equal times. The difference is that with extra
checks, it's detected earlier and an exception is thrown. Without the
check, the code goes ahead and equal times result in an uncaught error
later on (maybe a division by zero or something like it.)

> Is it possible that a curve with a valid set of dates/discount factors
> (e.g., spaced from each other by yearly gaps) can blow up at run time
> even in release mode? (this would seem a bug to me)

Yes, it should be fixed. We should find out where the error occurs
without checks (the most straightforward way would be to run the thing
in the debugger without extra checks) and add either a special case for
equal times, or at least an exception that can be caught. Are you
willing to help on this?

Later,
        Luigi


--

Academic: a term of opprobrium applied to those that do their job well
by those who cannot.
-- Sir Ernest Gowers



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi Frank,

On Thu, 2007-11-01 at 22:12 +0100, Frank Hövermann wrote:

> When I change the value which is passed to .withTimeSteps starting
> from 1 to, say, 5 in the case of non-flat vol term structure (but flat
> skew) which is defined by 5 points on the time scale, the value 1
> results in a plain vanilla call option's value which corresponds to
> the start vol (all else being equal). Increasing the number of time
> steps the option's value seems to approach the value of the closed
> form solution where the speed of convergence depends on the particular
> shape of the term structure in the neighborhood of maturity.
>  
> I would expect, especially in the case of one time step for this plain
> vanilla call, the vol to be taken as the terminal vol not the initial
> one. Am I wrong?

No, you're right. The problem is in the way that the Black-Scholes
stochastic process is discretized. By default, it uses Euler
discretization, which at each step simply takes the initial value (see
<ql/processes/eulerdiscretization.cpp>.)  You can obtain the behavior
you want by defining another discretization (you can do it by cloning
the Euler code and modify it) that takes the terminal value. Once you
have implemented it, you can pass it to the BlackScholesProcess
constructor so that it overrides the default behavior.  If you want, you
can implement more refined behaviors, too (such as integrating the
variance, or using some predictor-corrector algorithm.)

Luigi

P.S. If you implement the new class and want to contribute it, I'll be
glad to add it to the library.



--

The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users