[In response to] difficulty costructing PiecewiseYieldCurve with USD Libor fixes.

[BERTOCCHI NICHOLAS]

Dear Vinod,

 

your first problem is related to the different ways used by Libor indexes and yield curves to evaluate the settlement date. Libor indexes use the u.k. calendar to move 2 days forward and then adjust the settlement date taking care of local calendar (u.s. calendar in your case). Yield curves use only the calendar passed to the constructor (u.s. calendar). If you have a local holidays in the middle (for example in t+1), in the first case it will be considered as one of the two working days, in the second case it will be jumped. I suggest you to use another PiecewiseYieldCurve constructor in which you don't have to set the calendar and the settlement days to the curve but directly the settlement date. In this way you can specify as input the proper settlement date (2016-09-06 in your case).

Moving to the second point, if you pass two settlement days to the curve, any instrument with maturity in the first 2 days will be ignored. Curve settlement days different form 0 are used when you are bootstrapping a tenor curve (for example 3M curve) and you don’t have any information over the 2 days period before the value date of your first instrument (for example 3M deposit). By choosing 2 settlement days you are forcing the curve to start from t+2 (discount 1 at t+2). If you want to include the o/n rate and/or the t/n rate I suggest you to pass 0 settlement days to the curve.

Your last issue looks very strange. In your version of QuantLib (it is different in the last releases) the yield curve should use rate helper maturities as pillar dates. A deposit maturity is set equal to the Ibor index end date. I need to go deeper in the problem to give you an answer.

I hope it will help you.

Kind Regards,

 

Nicholas

Prima di stampare, pensa all'ambiente ** Think about the environment before printing

---

This e-mail is subject to terms available at the following link:
http://www.bancaimi.com/bancaimi/email_disclaimer.html.
Please read the hyperlink carefully as it contains the conditions governing any electronic communications between you and Banca IMI SpA. By messaging with Banca IMI SpA you agree to such terms and conditions of use. Banca IMI SpA may amend these terms and conditions at any time without notice. You should check the relevant webpage from time to time to review the current terms and conditions because they are binding on you. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Please note that, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited and may be unlawful.

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

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[VINOD RAJAKUMAR]

Thank you for the suggestions Nicholas.

With regards to your first proposal, I appreciate that QuantLib has enough features that I can calculate the settlement date myself, but I was hoping to avoid this since the objects passed to the constructor contain all the business/market logic needed. Perhaps I can propose this as a future enhancement to this object - a constructor that doesn't require settlement days, calendar or even a reference date and instead uses the IborIndex objects passed to it (thru the DepositRateHelpers) to correctly calculate settlement date. The IborIndex objects seem to contain a calendar and already compute value/reference date and maturity date correctly - the PiecewiseYieldCurve could just use those methods?

The second solution you propose in order to include o/n rates (T+0 settle) with longer-dated usdlibor maturities (T+2 settle) is not so straightforward unfortunately. If you pass in 0 as the settlement days (or even the actual reference date for the o/n rate), this has the side-effect of computing erroneous date-rate nodes for the other IborIndex rates passed to the PiecewiseYieldCurve. In order to recover the original fixes, you would have to modify the actual rate values slightly to account for slight differences in the computation of t when constructing the curve. You can try it out for yourself by changing the settlement to 0 in the sample program, and you will see you can not recover the original rates passed in (other than for the o/n rate).

Finally, were you able to replicate the issue with the date node for 1-month usdlibor for the rates fixed on 9/6 on the most recent version of QuantLib (v1.8) using my sample program? If it is fixed in a later version I can work on upgrading my libraries.

Best,

Vinod

On Tue, Sep 13, 2016 at 9:41 AM, BERTOCCHI NICHOLAS <[hidden email]> wrote:

Dear Vinod,

 

your first problem is related to the different ways used by Libor indexes and yield curves to evaluate the settlement date. Libor indexes use the u.k. calendar to move 2 days forward and then adjust the settlement date taking care of local calendar (u.s. calendar in your case). Yield curves use only the calendar passed to the constructor (u.s. calendar). If you have a local holidays in the middle (for example in t+1), in the first case it will be considered as one of the two working days, in the second case it will be jumped. I suggest you to use another PiecewiseYieldCurve constructor in which you don't have to set the calendar and the settlement days to the curve but directly the settlement date. In this way you can specify as input the proper settlement date (2016-09-06 in your case).

Moving to the second point, if you pass two settlement days to the curve, any instrument with maturity in the first 2 days will be ignored. Curve settlement days different form 0 are used when you are bootstrapping a tenor curve (for example 3M curve) and you don’t have any information over the 2 days period before the value date of your first instrument (for example 3M deposit). By choosing 2 settlement days you are forcing the curve to start from t+2 (discount 1 at t+2). If you want to include the o/n rate and/or the t/n rate I suggest you to pass 0 settlement days to the curve.

Your last issue looks very strange. In your version of QuantLib (it is different in the last releases) the yield curve should use rate helper maturities as pillar dates. A deposit maturity is set equal to the Ibor index end date. I need to go deeper in the problem to give you an answer.

I hope it will help you.

Kind Regards,

 

Nicholas

Prima di stampare, pensa all'ambiente ** Think about the environment before printing

---

This e-mail is subject to terms available at the following link:
http://www.bancaimi.com/bancaimi/email_disclaimer.html.
Please read the hyperlink carefully as it contains the conditions governing any electronic communications between you and Banca IMI SpA. By messaging with Banca IMI SpA you agree to such terms and conditions of use. Banca IMI SpA may amend these terms and conditions at any time without notice. You should check the relevant webpage from time to time to review the current terms and conditions because they are binding on you. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Please note that, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited and may be unlawful.

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

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

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

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi Vinod,

    I'm not sure I follow.  If you pass 0 days to the piecewise-curve constructor and either 0 or 2 days to the deposit-helper constructors according to their individual settle, the calculation will take that into account and reprice the rates exactly--or at least it did, last time I looked.  May you post a sample program that reproduces the issue?

Thanks,

    Luigi

On Wed, Sep 14, 2016 at 11:24 PM VINOD RAJAKUMAR <[hidden email]> wrote:

Thank you for the suggestions Nicholas.

With regards to your first proposal, I appreciate that QuantLib has enough features that I can calculate the settlement date myself, but I was hoping to avoid this since the objects passed to the constructor contain all the business/market logic needed. Perhaps I can propose this as a future enhancement to this object - a constructor that doesn't require settlement days, calendar or even a reference date and instead uses the IborIndex objects passed to it (thru the DepositRateHelpers) to correctly calculate settlement date. The IborIndex objects seem to contain a calendar and already compute value/reference date and maturity date correctly - the PiecewiseYieldCurve could just use those methods?

The second solution you propose in order to include o/n rates (T+0 settle) with longer-dated usdlibor maturities (T+2 settle) is not so straightforward unfortunately. If you pass in 0 as the settlement days (or even the actual reference date for the o/n rate), this has the side-effect of computing erroneous date-rate nodes for the other IborIndex rates passed to the PiecewiseYieldCurve. In order to recover the original fixes, you would have to modify the actual rate values slightly to account for slight differences in the computation of t when constructing the curve. You can try it out for yourself by changing the settlement to 0 in the sample program, and you will see you can not recover the original rates passed in (other than for the o/n rate).

Finally, were you able to replicate the issue with the date node for 1-month usdlibor for the rates fixed on 9/6 on the most recent version of QuantLib (v1.8) using my sample program? If it is fixed in a later version I can work on upgrading my libraries.

Best,

Vinod

On Tue, Sep 13, 2016 at 9:41 AM, BERTOCCHI NICHOLAS <[hidden email]> wrote:

Dear Vinod,

 

your first problem is related to the different ways used by Libor indexes and yield curves to evaluate the settlement date. Libor indexes use the u.k. calendar to move 2 days forward and then adjust the settlement date taking care of local calendar (u.s. calendar in your case). Yield curves use only the calendar passed to the constructor (u.s. calendar). If you have a local holidays in the middle (for example in t+1), in the first case it will be considered as one of the two working days, in the second case it will be jumped. I suggest you to use another PiecewiseYieldCurve constructor in which you don't have to set the calendar and the settlement days to the curve but directly the settlement date. In this way you can specify as input the proper settlement date (2016-09-06 in your case).

Moving to the second point, if you pass two settlement days to the curve, any instrument with maturity in the first 2 days will be ignored. Curve settlement days different form 0 are used when you are bootstrapping a tenor curve (for example 3M curve) and you don’t have any information over the 2 days period before the value date of your first instrument (for example 3M deposit). By choosing 2 settlement days you are forcing the curve to start from t+2 (discount 1 at t+2). If you want to include the o/n rate and/or the t/n rate I suggest you to pass 0 settlement days to the curve.

Your last issue looks very strange. In your version of QuantLib (it is different in the last releases) the yield curve should use rate helper maturities as pillar dates. A deposit maturity is set equal to the Ibor index end date. I need to go deeper in the problem to give you an answer.

I hope it will help you.

Kind Regards,

 

Nicholas

Prima di stampare, pensa all'ambiente ** Think about the environment before printing

---

This e-mail is subject to terms available at the following link:
http://www.bancaimi.com/bancaimi/email_disclaimer.html.
Please read the hyperlink carefully as it contains the conditions governing any electronic communications between you and Banca IMI SpA. By messaging with Banca IMI SpA you agree to such terms and conditions of use. Banca IMI SpA may amend these terms and conditions at any time without notice. You should check the relevant webpage from time to time to review the current terms and conditions because they are binding on you. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Please note that, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited and may be unlawful.

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

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi Vinod,

    [adding quantlib-users in cc as it might be useful to others]

apologies for taking so long to look into it. You're retrieving the wrong rate.  Starting from your Main_v1.cpp so that we use the correct calendar rule for the maturities:

- first, set the number of settlement days for the curve to 0 instead of 2;

- then, when extracting the rates to compare with the input, don't use the zeroRate method; that will give you the rate between the start of the curve (i.e., today's date) and the maturity, whereas the libor fixing is the rate between spot and the maturity.  To retrieve the correct rate, you have two possibilities:

1) calculate the correct start and end dates and use the forwardRate method instead, as in:

    boost::shared_ptr<QuantLib::IborIndex> index;

    if(vecTenor[i]=="1d") 

        index = boost::shared_ptr<QuantLib::IborIndex>(new QuantLib::USDLiborON);

    else

        index = boost::shared_ptr<QuantLib::IborIndex>(new QuantLib::USDLibor(QuantLib::PeriodParser::parse(vecTenor[i])));

    QuantLib::Date start = index->valueDate(dateFix);

    QuantLib::Date maturity = index->maturityDate(start);

    std::cout << QuantLib::io::iso_date(start) << "," << QuantLib::io::iso_date(maturity) << ",";

    std::cout << libor->forwardRate(start, maturity, QuantLib::Actual360(), QuantLib::Simple);

2) pass the curve to the index and let it do its job, as in:

    boost::shared_ptr<QuantLib::IborIndex> index;

    QuantLib::Handle<QuantLib::YieldTermStructure> h(libor);

    if(vecTenor[i]=="1d") 

        index = boost::shared_ptr<QuantLib::IborIndex>(new QuantLib::USDLiborON(h));

    else

        index = boost::shared_ptr<QuantLib::IborIndex>(new QuantLib::USDLibor(QuantLib::PeriodParser::parse(vecTenor[i]), h));

    std::cout << index->fixing(dateFix);

I've added both approaches to the Main_v3.cpp I'm attaching. They both work:

EvaluationDate: 2016-09-06

ReferenceDate:  2016-09-06

Curve nodes:

2016-09-06,0.00420438

2016-09-07,0.00420438

2016-09-15,0.00438472

2016-10-11,0.00511081

2016-11-08,0.00655011

2016-12-08,0.00830808

2017-03-08,0.01237149

2017-09-08,0.01542962

Check original rate fixes

 1d,2016-09-07,0.00420440,0.00420440,2016-09-06,2016-09-07,0.42044000 % Actual/360 simple compounding

 1w,2016-09-15,0.00443000,0.00443000,2016-09-08,2016-09-15,0.44300000 % Actual/360 simple compounding

 1m,2016-10-11,0.00516560,0.00516560,2016-09-08,2016-10-11,0.51656000 % Actual/360 simple compounding

 2m,2016-11-08,0.00663000,0.00663000,2016-09-08,2016-11-08,0.66300000 % Actual/360 simple compounding

 3m,2016-12-08,0.00840670,0.00840670,2016-09-08,2016-12-08,0.84067000 % Actual/360 simple compounding

 6m,2017-03-08,0.01250060,0.01250060,2016-09-08,2017-03-08,1.25006000 % Actual/360 simple compounding

12m,2017-09-08,0.01561330,0.01561330,2016-09-08,2017-09-08,1.56133000 % Actual/360 simple compounding

Hope this helps,

    Luigi

On Tue, Oct 4, 2016 at 8:47 PM VINOD RAJAKUMAR <[hidden email]> wrote:

Luigi,

I've attached two sample programs.

Main_v1.cpp should be identical to the original sample program I sent to demonstrate the issues I was having.

Main_v2.cpp modifies two lines per your instructions. in line 87, instead of using the DepositRateHelper constructor

> DepositRateHelper (const Handle< Quote > &rate, const boost::shared_ptr< IborIndex > &iborIndex)

it uses

> DepositRateHelper (Rate rate, const Period &tenor, Natural fixingDays, const Calendar &calendar, BusinessDayConvention convention, bool endOfMonth, const DayCounter &dayCounter)

so that I can pass 0 or 2 fixing days based on their settle convention (I actually just use the IborIndex public methods since it seems to contain the correct conventions already)

and in line 104, instead of passing in 2 days to the PiecewiseYieldConstructor, I pass in 0.

>    libor(new QuantLib::PiecewiseYieldCurve<QuantLib::ZeroYield, QuantLib::Linear>(2,

>    libor(new QuantLib::PiecewiseYieldCurve<QuantLib::ZeroYield, QuantLib::Linear>(0,

here is the output from v2 when invoked on the 20160906 input file for libor (I excluded some initial debugging output but it is contained in the output files attached):

...
EvaluationDate: 2016-09-06
ReferenceDate:  2016-09-06
Curve nodes:
2016-09-06,0.00420438
2016-09-07,0.00420438
2016-09-15,0.00438472
2016-10-10,0.00510927
2016-11-08,0.00655011
2016-12-08,0.00830808
2017-03-08,0.<a href="tel:0123%207149" value="[phone]" class="gmail_msg" target="_blank">01237149
2017-09-08,0.<a href="tel:015%2042962" value="[phone]" class="gmail_msg" target="_blank">01542962
Check original rate fixes
 1d,2016-09-07,0.00420440,0.42044000 % Actual/360 simple compounding
 1w,2016-09-15,0.00443000,0.43849628 % Actual/360 simple compounding
 1m,2016-10-11,0.00516560,0.51602458 % Actual/360 simple compounding
 2m,2016-11-08,0.00663000,0.65538640 % Actual/360 simple compounding
 3m,2016-12-08,0.00840670,0.83170065 % Actual/360 simple compounding
 6m,2017-03-08,0.<a href="tel:0125%200060" value="[phone]" class="gmail_msg" target="_blank">01250060,1.24104681 % Actual/360 simple compounding
12m,2017-09-08,0.<a href="tel:015%2061330" value="[phone]" class="gmail_msg" target="_blank">01561330,1.55516138 % Actual/360 simple compounding

Only the rate for overnight libor matches (highlighted in green), the rest do not match (highlighted orange).

-Vinod

On Mon, Oct 3, 2016 at 11:20 AM, Luigi Ballabio <[hidden email]> wrote:

Hi Vinod,

    I'm not sure I follow.  If you pass 0 days to the piecewise-curve constructor and either 0 or 2 days to the deposit-helper constructors according to their individual settle, the calculation will take that into account and reprice the rates exactly--or at least it did, last time I looked.  May you post a sample program that reproduces the issue?

Thanks,

    Luigi

On Wed, Sep 14, 2016 at 11:24 PM VINOD RAJAKUMAR <[hidden email]> wrote:

Thank you for the suggestions Nicholas.

With regards to your first proposal, I appreciate that QuantLib has enough features that I can calculate the settlement date myself, but I was hoping to avoid this since the objects passed to the constructor contain all the business/market logic needed. Perhaps I can propose this as a future enhancement to this object - a constructor that doesn't require settlement days, calendar or even a reference date and instead uses the IborIndex objects passed to it (thru the DepositRateHelpers) to correctly calculate settlement date. The IborIndex objects seem to contain a calendar and already compute value/reference date and maturity date correctly - the PiecewiseYieldCurve could just use those methods?

The second solution you propose in order to include o/n rates (T+0 settle) with longer-dated usdlibor maturities (T+2 settle) is not so straightforward unfortunately. If you pass in 0 as the settlement days (or even the actual reference date for the o/n rate), this has the side-effect of computing erroneous date-rate nodes for the other IborIndex rates passed to the PiecewiseYieldCurve. In order to recover the original fixes, you would have to modify the actual rate values slightly to account for slight differences in the computation of t when constructing the curve. You can try it out for yourself by changing the settlement to 0 in the sample program, and you will see you can not recover the original rates passed in (other than for the o/n rate).

Finally, were you able to replicate the issue with the date node for 1-month usdlibor for the rates fixed on 9/6 on the most recent version of QuantLib (v1.8) using my sample program? If it is fixed in a later version I can work on upgrading my libraries.

Best,

Vinod

On Tue, Sep 13, 2016 at 9:41 AM, BERTOCCHI NICHOLAS <[hidden email]> wrote:

Dear Vinod,

 

your first problem is related to the different ways used by Libor indexes and yield curves to evaluate the settlement date. Libor indexes use the u.k. calendar to move 2 days forward and then adjust the settlement date taking care of local calendar (u.s. calendar in your case). Yield curves use only the calendar passed to the constructor (u.s. calendar). If you have a local holidays in the middle (for example in t+1), in the first case it will be considered as one of the two working days, in the second case it will be jumped. I suggest you to use another PiecewiseYieldCurve constructor in which you don't have to set the calendar and the settlement days to the curve but directly the settlement date. In this way you can specify as input the proper settlement date (2016-09-06 in your case).

Moving to the second point, if you pass two settlement days to the curve, any instrument with maturity in the first 2 days will be ignored. Curve settlement days different form 0 are used when you are bootstrapping a tenor curve (for example 3M curve) and you don’t have any information over the 2 days period before the value date of your first instrument (for example 3M deposit). By choosing 2 settlement days you are forcing the curve to start from t+2 (discount 1 at t+2). If you want to include the o/n rate and/or the t/n rate I suggest you to pass 0 settlement days to the curve.

Your last issue looks very strange. In your version of QuantLib (it is different in the last releases) the yield curve should use rate helper maturities as pillar dates. A deposit maturity is set equal to the Ibor index end date. I need to go deeper in the problem to give you an answer.

I hope it will help you.

Kind Regards,

 

Nicholas

Prima di stampare, pensa all'ambiente ** Think about the environment before printing

---

This e-mail is subject to terms available at the following link:
http://www.bancaimi.com/bancaimi/email_disclaimer.html.
Please read the hyperlink carefully as it contains the conditions governing any electronic communications between you and Banca IMI SpA. By messaging with Banca IMI SpA you agree to such terms and conditions of use. Banca IMI SpA may amend these terms and conditions at any time without notice. You should check the relevant webpage from time to time to review the current terms and conditions because they are binding on you. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Please note that, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited and may be unlawful.

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

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users