decreasing discount factors

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

decreasing discount factors

Ferdinando M. Ametrano-2
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



Reply | Threaded
Open this post in threaded view
|

Re: decreasing discount factors

Marco Marchioro-2
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



Reply | Threaded
Open this post in threaded view
|

RE: decreasing discount factors

Andre Louw-2
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.


Reply | Threaded
Open this post in threaded view
|

RE: decreasing discount factors

Ferdinando M. Ametrano-2
>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
this is simply impossible in the real world, as it would imply
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



Reply | Threaded
Open this post in threaded view
|

RE: decreasing discount factors

Luigi Ballabio-2
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



Reply | Threaded
Open this post in threaded view
|

RE: decreasing discount factors

Ferdinando M. Ametrano-2
>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



Reply | Threaded
Open this post in threaded view
|

QuantLib-SWIG and Visual Studio

Marco Marchioro-2
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.




Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-SWIG and Visual Studio

Marco Marchioro-2
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.