Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/curve-generation-issues-tp1529p1532.html
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