Hi Marco
in your commit described below you are removing a worthwhile check that helped me detect many problems in my applications. Maybe I'm missing something but I can't see why we shouldn't require decreasing discount factors. Decreasing discounts imply non-negative interest rates, which should be a safe assumption. Are you really dealing with negative interest rates? If this is the case I'm afraid discountcurve is not the only place where we are assuming non-negative interest rates .... ciao -- Nando >From: Marco Marchioro <[hidden email]> >Subject: [Quantlib-cvs] CVS: QuantLib/ql/TermStructures >discountcurve.cpp,1.13,1.14 > >Update of /cvsroot/quantlib/QuantLib/ql/TermStructures >In directory usw-pr-cvs1:/tmp/cvs-serv31653 > >Modified Files: > discountcurve.cpp >Log Message: >relaxed requirement on decreasing discounts > >Index: discountcurve.cpp >=================================================================== >RCS file: /cvsroot/quantlib/QuantLib/ql/TermStructures/discountcurve.cpp,v >retrieving revision 1.13 >retrieving revision 1.14 >diff -C2 -r1.13 -r1.14 >*** discountcurve.cpp 29 Oct 2002 14:14:18 -0000 1.13 >--- discountcurve.cpp 7 Nov 2002 13:34:20 -0000 1.14 >*************** >*** 53,57 **** > QL_REQUIRE(dates_[i]>dates_[i-1], > "DiscountCurve::DiscountCurve : invalid date"); >! QL_REQUIRE(discounts_[i]<=discounts_[i-1], > "DiscountCurve::DiscountCurve : invalid discount"); > times_[i] = dayCounter_.yearFraction(dates_[0], >--- 53,57 ---- > QL_REQUIRE(dates_[i]>dates_[i-1], > "DiscountCurve::DiscountCurve : invalid date"); >! QL_REQUIRE(discounts_[i] > 0.0, > "DiscountCurve::DiscountCurve : invalid discount"); > times_[i] = dayCounter_.yearFraction(dates_[0], > > > >------------------------------------------------------- >This sf.net email is sponsored by: See the NEW Palm >Tungsten T handheld. Power & Color in a compact size! >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >_______________________________________________ >Quantlib-cvs mailing list >[hidden email] >https://lists.sourceforge.net/lists/listinfo/quantlib-cvs |
Hi,
I realized now that I should have consulted the mailing list first(sorry about that). The only assumptions that we need in building the discount curve is to have positive discounts, not that these should be decreasing. I should be able to set my curve to my taste as long as that does not break the interpolation. If you need a check on your input rates I think this should be done elsewhere. Why should we prevent the use of negative rates(and they do exists in real life) in one of the few places where we do not actually need to enforce them. Marco. At 03:19 PM 11/7/02 +0100, Ferdinando Ametrano wrote: >Hi Marco > >in your commit described below you are removing a worthwhile check that >helped me detect many problems in my applications. > >Maybe I'm missing something but I can't see why we shouldn't require >decreasing discount factors. Decreasing discounts imply non-negative >interest rates, which should be a safe assumption. Are you really dealing >with negative interest rates? >If this is the case I'm afraid discountcurve is not the only place where >we are assuming non-negative interest rates .... > >ciao -- Nando > >>From: Marco Marchioro <[hidden email]> >>Subject: [Quantlib-cvs] CVS: QuantLib/ql/TermStructures >>discountcurve.cpp,1.13,1.14 >> >>Update of /cvsroot/quantlib/QuantLib/ql/TermStructures >>In directory usw-pr-cvs1:/tmp/cvs-serv31653 >> >>Modified Files: >> discountcurve.cpp >>Log Message: >>relaxed requirement on decreasing discounts >> >>Index: discountcurve.cpp >>=================================================================== >>RCS file: /cvsroot/quantlib/QuantLib/ql/TermStructures/discountcurve.cpp,v >>retrieving revision 1.13 >>retrieving revision 1.14 >>diff -C2 -r1.13 -r1.14 >>*** discountcurve.cpp 29 Oct 2002 14:14:18 -0000 1.13 >>--- discountcurve.cpp 7 Nov 2002 13:34:20 -0000 1.14 >>*************** >>*** 53,57 **** >> QL_REQUIRE(dates_[i]>dates_[i-1], >> "DiscountCurve::DiscountCurve : invalid date"); >>! QL_REQUIRE(discounts_[i]<=discounts_[i-1], >> "DiscountCurve::DiscountCurve : invalid discount"); >> times_[i] = dayCounter_.yearFraction(dates_[0], >>--- 53,57 ---- >> QL_REQUIRE(dates_[i]>dates_[i-1], >> "DiscountCurve::DiscountCurve : invalid date"); >>! QL_REQUIRE(discounts_[i] > 0.0, >> "DiscountCurve::DiscountCurve : invalid discount"); >> times_[i] = dayCounter_.yearFraction(dates_[0], >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by: See the NEW Palm >>Tungsten T handheld. Power & Color in a compact size! >>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >>_______________________________________________ >>Quantlib-cvs mailing list >>[hidden email] >>https://lists.sourceforge.net/lists/listinfo/quantlib-cvs |
In reply to this post by Ferdinando M. Ametrano-2
Hi,
Just my penny's worth. Using the discount factor formula, if the change in rates is big enough relative to the time period, it is quite possible for the discount factors to increase! E.g: Rate Days Df 3M 2.30 90/365 0.99436 6M 1.10 180/365 0.99460 This is unlikely but of course not impossible - never ASS-U-ME, it makes an ASS out of U and ME! Thanx Andre ------------------------------------------------------------------------- This e-mail is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged, proprietary to the company and protected by law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. Opinions, conclusions and other information in this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it. |
>Using the discount factor formula, if the change in rates is big enough
this is simply impossible in the real world, as it would imply
>relative to the time period, it is quite possible for the discount factors >to increase! > >E.g: > > Rate Days Df > 3M 2.30 90/365 0.99436 > 6M 1.10 180/365 0.99460 > >This is unlikely but of course not impossible a forward 3x6 rate of -0.10%, that is a negative interest rate, way out of order with rates at a level of 1%-2% It is not impossible to have negative interest rate, but this happened in Japan on very short spot rates (overnight, tom-next). Negative forward rates would be an arbitrage opportunity. Which leads me back to my original argument. Marco, what kind of benefit are you getting out of the "relaxed" constraints? What are you using the discount curve for? I'm not asking this out of curiosity, but since it would put a considerable burden on my applications I would prefer to revert your commit unless I do understand the real benefit of the change. Not that I'm in a hurry, since I will not need a new executable at work in the next few months. Just in case you wonder what kind of burden I'm talking about: I receive a discount curve as input from another application that uses FinCAD libraries. When this application has problems it usually output a curve with non-decreasing discounts, and that QuantLib requirement help me immediately detect such problems. I've also investigated how it is possible for that application to output non-decreasing discounts and, you know what, the problem is with a flawed Reuters/Bloomberg feed that provides wrong market rates, of the kind Andre has given as example, and that are not possible for EUR/USD/YEN these days. This said I'm not against checking the discounts in an intermediate layer, but I would like to understand which benefit we get in return. cooperatively yours -- Nando |
At 03:09 PM 11/8/02 +0100, Ferdinando Ametrano wrote:
> Negative forward rates would be an arbitrage opportunity. Not if the two spot rates from which you bootstrap the curve are both on the bid side or both on the ask side. >Which leads me back to my original argument. Marco, what kind of benefit >are you getting out of the "relaxed" constraints? What are you using the >discount curve for? Why, to represent market data, of course :) A customer using our libraries stumbled upon a legitimate case such as the one Andre' presented. They were including overnight rates, and the impedence mismatch between the very-short and the short rate region caused a hump on the discounts---a very real one, but not an arbitrage opportunity, mind you, because they were on the same side. Combining a bid and an ask side would not give increasing discounts, of course. Bye, Luigi |
>They were including overnight rates, and the impedence mismatch between
>the very-short and the short rate region caused a hump on the >discounts---a very real one, but not an arbitrage opportunity, mind you, >because they were on the same side. Combining a bid and an ask side would >not give increasing discounts, of course. got it, thank you. ciao -- Nando |
Hi All,
I compiled QuantLib-SWIG/Python with VisualStudio, using SWIG 1.3.16: it seems to work. I've also added a win32 script wrap.bat to help the generation of the wrappers but I do not know how to do it automatically within VisualStudio. Anybody wants to try? Marco. |
Hi,
the problem was fixed with the help of Luigi. On my computer everything runs ok. Unfortunatly, there are still many warnings that I was able to remove only editing the swig.swg file. wrap.bat was removed from cvs. take care, Marco. At 12:03 PM 11/11/02 +0100, Marco Marchioro wrote: >Hi All, >I compiled QuantLib-SWIG/Python with VisualStudio, using SWIG 1.3.16: >it seems to work. > >I've also added a win32 script wrap.bat to help the generation of the wrappers >but I do not know how to do it automatically within VisualStudio. > >Anybody wants to try? > >Marco. |
Free forum by Nabble | Edit this page |