pricing a floating rate bond

[Steve]

I am trying to price a floating rate bond that depends on the rate of a Treasury instrument. For simplicity, the rate and the date are imported from the file. But I used IborIndex class for the rate of the instrument. Unsurprisingly, the result is way off. So I have a few questions on this topic:

1 is there an equivalent index class for the Treasury instrument, like IborIndex for LIBOR, in QuantLib?

2 if the answer is no, is it possible to build a class like TreasuryIndex by extending InterestRateIndex? What would be the challenge in building TreasuryIndex?

3 Is it possible to use IborIndex for a Treasury instrument by tweaking the calendar alone? What else needs to be done to make it work?

4      Can someone point me to the right direction on how to leverage QuantLib classes to price a floating rate bond that uses a Treasury instrument as the index after a peek at the code?

Really appreciate your help!

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
> I am trying to price a floating rate bond that depends on the rate of a
> Treasury instrument. For simplicity, the rate and the date are imported from
> the file. But I used IborIndex class for the rate of the instrument.
> Unsurprisingly, the result is way off. So I have a few questions on this
> topic:
>
> 1 is there an equivalent index class for the Treasury instrument, like
> IborIndex for LIBOR, in QuantLib?

Not as such.  You might use IborIndex as a proxy, provided that the
conventions match; for instance, the LIBOR rate is simply compounded,
with an Actual/360 day-count convention in the case of USD LIBOR.  As
far as I know, T-bills are quoted as a discount; how is the rate of
your Treasury instrument derived from that?  And instead of looking at
the price of the bond (that is, at the sum of the coupons, which
muddies things), have you tried first looking at forecast IborIndex
fixings to see if they match the rates you expect?

> 2 if the answer is no, is it possible to build a class like TreasuryIndex by
> extending InterestRateIndex? What would be the challenge in building
> TreasuryIndex?

You would have to implement the forecastFixing method so that it
returns the T-Bill rate. Basically, you'd have to be able to forecast
the rate off your treasury curve. (You'd also have to implement the
maturityDate method, but that's easy).

> 3 Is it possible to use IborIndex for a Treasury instrument by tweaking the
> calendar alone? What else needs to be done to make it work?

See above. It depends on how much the conventions differ.

> 4      Can someone point me to the right direction on how to leverage
> QuantLib classes to price a floating rate bond that uses a Treasury
> instrument as the index after a peek at the code?

If using IborIndex fails, inheriting from InterestRateIndex shouldn't
be that difficult. Once you have a rate class, you should be able to
use the existing classes as you did in your code.

Let me know how it works.

Later,
    Luigi


--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luigi,

I tried to use IborIndex to price the floating note. The result is about 0.0036% off from the correct answer. There are many factors that contribute to this discrepancy. But I think the main reason is that the forecastfixing is about 0.013% off from the index rate. Below are the code printing out forecastfixing and some of the index rate:

for(int i=0;i<AccuralStart.size();i++){

if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] < settlementDate){

FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);

junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i]) << " +++ " << IndexRate[i] << endl;

}

if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >= settlementDate){

junk << AccuralStart[i] << " ``` " << FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] << endl;

}

}

September 11th, 2012 +++ 0.001 +++ 0.001

September 12th, 2012 +++ 0.001 +++ 0.001

September 13th, 2012 +++ 0.001 +++ 0.001

September 14th, 2012 +++ 0.001 +++ 0.001

September 17th, 2012 +++ 0.001 +++ 0.001

September 18th, 2012 +++ 0.001 +++ 0.001

September 19th, 2012 ``` 0.00105014 ``` 0.001

September 20th, 2012 ``` 0.00105014 ``` 0.00105

September 21st, 2012 ``` 0.00105014 ``` 0.00105

September 24th, 2012 ``` 0.00105014 ``` 0.00105

September 25th, 2012 ``` 0.00105014 ``` 0.00105

September 26th, 2012 ``` 0.00105014 ``` 0.00105

September 27th, 2012 ``` 0.00105014 ``` 0.00105

September 28th, 2012 ``` 0.00105014 ``` 0.00105

Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index rate after the settlement date, Sept 19th, 2012, all the way to the maturity date. Can you or anyone to help me to understand where 0.00000014 comes from?

Thanks

On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio <[hidden email]> wrote:

On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
> I am trying to price a floating rate bond that depends on the rate of a
> Treasury instrument. For simplicity, the rate and the date are imported from
> the file. But I used IborIndex class for the rate of the instrument.
> Unsurprisingly, the result is way off. So I have a few questions on this
> topic:
>
> 1 is there an equivalent index class for the Treasury instrument, like
> IborIndex for LIBOR, in QuantLib?

Not as such.  You might use IborIndex as a proxy, provided that the
conventions match; for instance, the LIBOR rate is simply compounded,
with an Actual/360 day-count convention in the case of USD LIBOR.  As
far as I know, T-bills are quoted as a discount; how is the rate of
your Treasury instrument derived from that?  And instead of looking at
the price of the bond (that is, at the sum of the coupons, which
muddies things), have you tried first looking at forecast IborIndex
fixings to see if they match the rates you expect?

> 2 if the answer is no, is it possible to build a class like TreasuryIndex by
> extending InterestRateIndex? What would be the challenge in building
> TreasuryIndex?

You would have to implement the forecastFixing method so that it
returns the T-Bill rate. Basically, you'd have to be able to forecast
the rate off your treasury curve. (You'd also have to implement the
maturityDate method, but that's easy).

> 3 Is it possible to use IborIndex for a Treasury instrument by tweaking the
> calendar alone? What else needs to be done to make it work?

See above. It depends on how much the conventions differ.

> 4      Can someone point me to the right direction on how to leverage
> QuantLib classes to price a floating rate bond that uses a Treasury
> instrument as the index after a peek at the code?

If using IborIndex fails, inheriting from InterestRateIndex shouldn't
be that difficult. Once you have a rate class, you should be able to
use the existing classes as you did in your code.

Let me know how it works.

Later,
    Luigi


--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Steve,
    may you send the data files you're using so that we can actually
run your code?

Luigi

On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:

> Luigi,
>
> I tried to use IborIndex to price the floating note. The result is about
> 0.0036% off from the correct answer. There are many factors that contribute
> to this discrepancy. But I think the main reason is that the forecastfixing
> is about 0.013% off from the index rate. Below are the code printing out
> forecastfixing and some of the index rate:
> for(int i=0;i<AccuralStart.size();i++){
> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
> settlementDate){
> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i]) << "
> +++ " << IndexRate[i] << endl;
> }
> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
> settlementDate){
> junk << AccuralStart[i] << " ``` " <<
> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
> endl;
> }
> }
>
> September 11th, 2012 +++ 0.001 +++ 0.001
> September 12th, 2012 +++ 0.001 +++ 0.001
> September 13th, 2012 +++ 0.001 +++ 0.001
> September 14th, 2012 +++ 0.001 +++ 0.001
> September 17th, 2012 +++ 0.001 +++ 0.001
> September 18th, 2012 +++ 0.001 +++ 0.001
> September 19th, 2012 ``` 0.00105014 ``` 0.001
> September 20th, 2012 ``` 0.00105014 ``` 0.00105
> September 21st, 2012 ``` 0.00105014 ``` 0.00105
> September 24th, 2012 ``` 0.00105014 ``` 0.00105
> September 25th, 2012 ``` 0.00105014 ``` 0.00105
> September 26th, 2012 ``` 0.00105014 ``` 0.00105
> September 27th, 2012 ``` 0.00105014 ``` 0.00105
> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>
> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index rate
> after the settlement date, Sept 19th, 2012, all the way to the maturity
> date. Can you or anyone to help me to understand where 0.00000014 comes
> from?
>
> Thanks
>
>
> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>> > I am trying to price a floating rate bond that depends on the rate of a
>> > Treasury instrument. For simplicity, the rate and the date are imported
>> > from
>> > the file. But I used IborIndex class for the rate of the instrument.
>> > Unsurprisingly, the result is way off. So I have a few questions on this
>> > topic:
>> >
>> > 1 is there an equivalent index class for the Treasury instrument, like
>> > IborIndex for LIBOR, in QuantLib?
>>
>> Not as such.  You might use IborIndex as a proxy, provided that the
>> conventions match; for instance, the LIBOR rate is simply compounded,
>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>> far as I know, T-bills are quoted as a discount; how is the rate of
>> your Treasury instrument derived from that?  And instead of looking at
>> the price of the bond (that is, at the sum of the coupons, which
>> muddies things), have you tried first looking at forecast IborIndex
>> fixings to see if they match the rates you expect?
>>
>> > 2 if the answer is no, is it possible to build a class like
>> > TreasuryIndex by
>> > extending InterestRateIndex? What would be the challenge in building
>> > TreasuryIndex?
>>
>> You would have to implement the forecastFixing method so that it
>> returns the T-Bill rate. Basically, you'd have to be able to forecast
>> the rate off your treasury curve. (You'd also have to implement the
>> maturityDate method, but that's easy).
>>
>> > 3 Is it possible to use IborIndex for a Treasury instrument by tweaking
>> > the
>> > calendar alone? What else needs to be done to make it work?
>>
>> See above. It depends on how much the conventions differ.
>>
>> > 4      Can someone point me to the right direction on how to leverage
>> > QuantLib classes to price a floating rate bond that uses a Treasury
>> > instrument as the index after a peek at the code?
>>
>> If using IborIndex fails, inheriting from InterestRateIndex shouldn't
>> be that difficult. Once you have a rate class, you should be able to
>> use the existing classes as you did in your code.
>>
>> Let me know how it works.
>>
>> Later,
>>     Luigi
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Steve,
    InterpolatedZeroCurve expects continuously compounded zero rates,
so the 0.00105 rate you're passing gets interpreted as such.  When you
later ask for the index fixing, the code calculates the corresponding
simply compounded rate, which is the 0.00105014 you're seeing (it's
basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
in your case and r1 = 0.00105).  You can try converting your 0.00105
to the correspondingly continuously compounded rate (same formula as
above, but inverted) and pass that one to the curve.

However, this will work only as long as the rate is constant. If the
forecast index fixings vary in time, the zero rates will no longer be
the same as the index rates, even converting the compounding (the zero
rates are the average of the forward rates).  You'd be much better off
if your system could give you, for instance, sampled discount factors
at the same dates. Otherwise you'll have to figure out the zero rates
or the discount factors yourself.

Hope this helps,
    Luigi



On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
<[hidden email]> wrote:

> Steve,
>     may you send the data files you're using so that we can actually
> run your code?
>
> Luigi
>
> On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>> Luigi,
>>
>> I tried to use IborIndex to price the floating note. The result is about
>> 0.0036% off from the correct answer. There are many factors that contribute
>> to this discrepancy. But I think the main reason is that the forecastfixing
>> is about 0.013% off from the index rate. Below are the code printing out
>> forecastfixing and some of the index rate:
>> for(int i=0;i<AccuralStart.size();i++){
>> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>> settlementDate){
>> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i]) << "
>> +++ " << IndexRate[i] << endl;
>> }
>> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>> settlementDate){
>> junk << AccuralStart[i] << " ``` " <<
>> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
>> endl;
>> }
>> }
>>
>> September 11th, 2012 +++ 0.001 +++ 0.001
>> September 12th, 2012 +++ 0.001 +++ 0.001
>> September 13th, 2012 +++ 0.001 +++ 0.001
>> September 14th, 2012 +++ 0.001 +++ 0.001
>> September 17th, 2012 +++ 0.001 +++ 0.001
>> September 18th, 2012 +++ 0.001 +++ 0.001
>> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>
>> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index rate
>> after the settlement date, Sept 19th, 2012, all the way to the maturity
>> date. Can you or anyone to help me to understand where 0.00000014 comes
>> from?
>>
>> Thanks
>>
>>
>> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> > I am trying to price a floating rate bond that depends on the rate of a
>>> > Treasury instrument. For simplicity, the rate and the date are imported
>>> > from
>>> > the file. But I used IborIndex class for the rate of the instrument.
>>> > Unsurprisingly, the result is way off. So I have a few questions on this
>>> > topic:
>>> >
>>> > 1 is there an equivalent index class for the Treasury instrument, like
>>> > IborIndex for LIBOR, in QuantLib?
>>>
>>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> your Treasury instrument derived from that?  And instead of looking at
>>> the price of the bond (that is, at the sum of the coupons, which
>>> muddies things), have you tried first looking at forecast IborIndex
>>> fixings to see if they match the rates you expect?
>>>
>>> > 2 if the answer is no, is it possible to build a class like
>>> > TreasuryIndex by
>>> > extending InterestRateIndex? What would be the challenge in building
>>> > TreasuryIndex?
>>>
>>> You would have to implement the forecastFixing method so that it
>>> returns the T-Bill rate. Basically, you'd have to be able to forecast
>>> the rate off your treasury curve. (You'd also have to implement the
>>> maturityDate method, but that's easy).
>>>
>>> > 3 Is it possible to use IborIndex for a Treasury instrument by tweaking
>>> > the
>>> > calendar alone? What else needs to be done to make it work?
>>>
>>> See above. It depends on how much the conventions differ.
>>>
>>> > 4      Can someone point me to the right direction on how to leverage
>>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> > instrument as the index after a peek at the code?
>>>
>>> If using IborIndex fails, inheriting from InterestRateIndex shouldn't
>>> be that difficult. Once you have a rate class, you should be able to
>>> use the existing classes as you did in your code.
>>>
>>> Let me know how it works.
>>>
>>> Later,
>>>     Luigi
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luiqi,

Thank you for your help. I found one of the root problems. I used InterpolatedZeroCurve to return the corresponding Interpolation instance, given a set of data point dated between 07/31/12 and 07/31/14. However, I intended to set 09/19/12 as the settlement date and I did so in the program using Settings::instance().evaluationDate(). But I just found out that the discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in discount factors and in turn in clean and dirty prices. Please see the attachment for the program. I wonder why assigning Settings doesn't work. Do I need to define YieldTermStructure instance with a specified reference date?

===========setting evaluation date

Natural settlementDays = 1;

Integer fixingDays = 4;

DayCounter DMCalcCounter = Actual360();

Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);

   Date settlementDate(19, September, 2012);

        // must be a business day

        settlementDate = DMCalccalendar.adjust(settlementDate);

        Date todaysDate = DMCalccalendar.advance(settlementDate, -fixingDays, Days);

cout << "Today is " << todaysDate << endl;

        // nothing to do with Date::todaysDate

        Settings::instance().evaluationDate() = todaysDate;

=============discount factor 

0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding

0 discount factor July 31st, 2012 ^^^ 1

On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]> wrote:

Steve,
    InterpolatedZeroCurve expects continuously compounded zero rates,
so the 0.00105 rate you're passing gets interpreted as such.  When you
later ask for the index fixing, the code calculates the corresponding
simply compounded rate, which is the 0.00105014 you're seeing (it's
basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
in your case and r1 = 0.00105).  You can try converting your 0.00105
to the correspondingly continuously compounded rate (same formula as
above, but inverted) and pass that one to the curve.

However, this will work only as long as the rate is constant. If the
forecast index fixings vary in time, the zero rates will no longer be
the same as the index rates, even converting the compounding (the zero
rates are the average of the forward rates).  You'd be much better off
if your system could give you, for instance, sampled discount factors
at the same dates. Otherwise you'll have to figure out the zero rates
or the discount factors yourself.

Hope this helps,
    Luigi

On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
<[hidden email]> wrote:
> Steve,
>     may you send the data files you're using so that we can actually
> run your code?
>
> Luigi
>
> On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>> Luigi,
>>
>> I tried to use IborIndex to price the floating note. The result is about
>> 0.0036% off from the correct answer. There are many factors that contribute
>> to this discrepancy. But I think the main reason is that the forecastfixing
>> is about 0.013% off from the index rate. Below are the code printing out
>> forecastfixing and some of the index rate:
>> for(int i=0;i<AccuralStart.size();i++){
>> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>> settlementDate){
>> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i]) << "
>> +++ " << IndexRate[i] << endl;
>> }
>> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>> settlementDate){
>> junk << AccuralStart[i] << " ``` " <<
>> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
>> endl;
>> }
>> }
>>
>> September 11th, 2012 +++ 0.001 +++ 0.001
>> September 12th, 2012 +++ 0.001 +++ 0.001
>> September 13th, 2012 +++ 0.001 +++ 0.001
>> September 14th, 2012 +++ 0.001 +++ 0.001
>> September 17th, 2012 +++ 0.001 +++ 0.001
>> September 18th, 2012 +++ 0.001 +++ 0.001
>> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>
>> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index rate
>> after the settlement date, Sept 19th, 2012, all the way to the maturity
>> date. Can you or anyone to help me to understand where 0.00000014 comes
>> from?
>>
>> Thanks
>>
>>
>> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> > I am trying to price a floating rate bond that depends on the rate of a
>>> > Treasury instrument. For simplicity, the rate and the date are imported
>>> > from
>>> > the file. But I used IborIndex class for the rate of the instrument.
>>> > Unsurprisingly, the result is way off. So I have a few questions on this
>>> > topic:
>>> >
>>> > 1 is there an equivalent index class for the Treasury instrument, like
>>> > IborIndex for LIBOR, in QuantLib?
>>>
>>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> your Treasury instrument derived from that?  And instead of looking at
>>> the price of the bond (that is, at the sum of the coupons, which
>>> muddies things), have you tried first looking at forecast IborIndex
>>> fixings to see if they match the rates you expect?
>>>
>>> > 2 if the answer is no, is it possible to build a class like
>>> > TreasuryIndex by
>>> > extending InterestRateIndex? What would be the challenge in building
>>> > TreasuryIndex?
>>>
>>> You would have to implement the forecastFixing method so that it
>>> returns the T-Bill rate. Basically, you'd have to be able to forecast
>>> the rate off your treasury curve. (You'd also have to implement the
>>> maturityDate method, but that's easy).
>>>
>>> > 3 Is it possible to use IborIndex for a Treasury instrument by tweaking
>>> > the
>>> > calendar alone? What else needs to be done to make it work?
>>>
>>> See above. It depends on how much the conventions differ.
>>>
>>> > 4      Can someone point me to the right direction on how to leverage
>>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> > instrument as the index after a peek at the code?
>>>
>>> If using IborIndex fails, inheriting from InterestRateIndex shouldn't
>>> be that difficult. Once you have a rate class, you should be able to
>>> use the existing classes as you did in your code.
>>>
>>> Let me know how it works.
>>>
>>> Later,
>>>     Luigi
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>



--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Steve,
    just setting the evaluation date doesn't work because if you
specify a reference date for the curve, it overrides the evaluation
date.  For InterpolatedZeroCurve, that's done implicitly by using the
first passed date as reference date.  (For more info, see
<http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).

Now, there are solutions for this, but there are different possible
behaviors when moving the reference date (as you tried to do when
changing the evaluation date) and you'll have to choose the solution
based on the one you want.

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

If you want to move the whole thing two months ahead (that is, to have
discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
at 09/17/14 equal to the one you had at 07/31/14 before) you'll also
have to rebuild your data set and build a new curve.  For other types
of curves (not for InterpolatedZeroCurve, though) it's possible to
have this done automatically when the evaluation date changes; see the
link I've posted above.

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

Later,
    Luigi


On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:

> Luiqi,
>
> Thank you for your help. I found one of the root problems. I used
> InterpolatedZeroCurve to return the corresponding Interpolation instance,
> given a set of data point dated between 07/31/12 and 07/31/14. However, I
> intended to set 09/19/12 as the settlement date and I did so in the program
> using Settings::instance().evaluationDate(). But I just found out that the
> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
> discount factors and in turn in clean and dirty prices. Please see the
> attachment for the program. I wonder why assigning Settings doesn't work. Do
> I need to define YieldTermStructure instance with a specified reference
> date?
>
> ===========setting evaluation date
> Natural settlementDays = 1;
> Integer fixingDays = 4;
>
> DayCounter DMCalcCounter = Actual360();
> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>
>    Date settlementDate(19, September, 2012);
>         // must be a business day
>         settlementDate = DMCalccalendar.adjust(settlementDate);
>
>         Date todaysDate = DMCalccalendar.advance(settlementDate,
> -fixingDays, Days);
> cout << "Today is " << todaysDate << endl;
>         // nothing to do with Date::todaysDate
>         Settings::instance().evaluationDate() = todaysDate;
>
> =============discount factor
> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
> 0 discount factor July 31st, 2012 ^^^ 1
>
>
>
>
>
> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> Steve,
>>     InterpolatedZeroCurve expects continuously compounded zero rates,
>> so the 0.00105 rate you're passing gets interpreted as such.  When you
>> later ask for the index fixing, the code calculates the corresponding
>> simply compounded rate, which is the 0.00105014 you're seeing (it's
>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>> to the correspondingly continuously compounded rate (same formula as
>> above, but inverted) and pass that one to the curve.
>>
>> However, this will work only as long as the rate is constant. If the
>> forecast index fixings vary in time, the zero rates will no longer be
>> the same as the index rates, even converting the compounding (the zero
>> rates are the average of the forward rates).  You'd be much better off
>> if your system could give you, for instance, sampled discount factors
>> at the same dates. Otherwise you'll have to figure out the zero rates
>> or the discount factors yourself.
>>
>> Hope this helps,
>>     Luigi
>>
>>
>>
>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> <[hidden email]> wrote:
>> > Steve,
>> >     may you send the data files you're using so that we can actually
>> > run your code?
>> >
>> > Luigi
>> >
>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>> >> Luigi,
>> >>
>> >> I tried to use IborIndex to price the floating note. The result is
>> >> about
>> >> 0.0036% off from the correct answer. There are many factors that
>> >> contribute
>> >> to this discrepancy. But I think the main reason is that the
>> >> forecastfixing
>> >> is about 0.013% off from the index rate. Below are the code printing
>> >> out
>> >> forecastfixing and some of the index rate:
>> >> for(int i=0;i<AccuralStart.size();i++){
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>> >> settlementDate){
>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i])
>> >> << "
>> >> +++ " << IndexRate[i] << endl;
>> >> }
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>> >> settlementDate){
>> >> junk << AccuralStart[i] << " ``` " <<
>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
>> >> endl;
>> >> }
>> >> }
>> >>
>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >>
>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>> >> rate
>> >> after the settlement date, Sept 19th, 2012, all the way to the maturity
>> >> date. Can you or anyone to help me to understand where 0.00000014 comes
>> >> from?
>> >>
>> >> Thanks
>> >>
>> >>
>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>> >>> > I am trying to price a floating rate bond that depends on the rate
>> >>> > of a
>> >>> > Treasury instrument. For simplicity, the rate and the date are
>> >>> > imported
>> >>> > from
>> >>> > the file. But I used IborIndex class for the rate of the instrument.
>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>> >>> > this
>> >>> > topic:
>> >>> >
>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>> >>> > like
>> >>> > IborIndex for LIBOR, in QuantLib?
>> >>>
>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>> >>> your Treasury instrument derived from that?  And instead of looking at
>> >>> the price of the bond (that is, at the sum of the coupons, which
>> >>> muddies things), have you tried first looking at forecast IborIndex
>> >>> fixings to see if they match the rates you expect?
>> >>>
>> >>> > 2 if the answer is no, is it possible to build a class like
>> >>> > TreasuryIndex by
>> >>> > extending InterestRateIndex? What would be the challenge in building
>> >>> > TreasuryIndex?
>> >>>
>> >>> You would have to implement the forecastFixing method so that it
>> >>> returns the T-Bill rate. Basically, you'd have to be able to forecast
>> >>> the rate off your treasury curve. (You'd also have to implement the
>> >>> maturityDate method, but that's easy).
>> >>>
>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>> >>> > tweaking
>> >>> > the
>> >>> > calendar alone? What else needs to be done to make it work?
>> >>>
>> >>> See above. It depends on how much the conventions differ.
>> >>>
>> >>> > 4      Can someone point me to the right direction on how to
>> >>> > leverage
>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>> >>> > instrument as the index after a peek at the code?
>> >>>
>> >>> If using IborIndex fails, inheriting from InterestRateIndex shouldn't
>> >>> be that difficult. Once you have a rate class, you should be able to
>> >>> use the existing classes as you did in your code.
>> >>>
>> >>> Let me know how it works.
>> >>>
>> >>> Later,
>> >>>     Luigi
>> >>>
>> >>>
>> >>> --
>> >>> <https://implementingquantlib.blogspot.com>
>> >>> <https://twitter.com/lballabio>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > <https://implementingquantlib.blogspot.com>
>> > <https://twitter.com/lballabio>
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luigi, 

Thank you very much for your time and help!

/////    approach A

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

//////

I use two yield term structure. TB13WksRateTermStructure, basically is the zero rate of original file whose evaluation date is 7/31 because the original file starts with 7/31/12. Then I use ImpliedTermStructure to set the evaluation date to 09/18 to create another yield term structure, discountRateTermStructureImplied. TB13WksRateTermStructure is the input for FloatingRateBond FRN and discountRateTermStructureImplied is linked to FRNEngine. But the result, dirty/clean price turns out to be the same as before the evaluation date of the yield term structured used for the engine was set to 09/18/12. Any way, it doesn't make difference on the price.

////////           Approach B

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

////////////

I remove the data before 09/18/12 from both the index file and the accrual date file. But the program errored out with 

AccuralStartSize = 680

IndexRateFileSize = 680

negative time (-0.0111111) given

I tried to locate where exactly the program failed. The closest I could get is

> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++

  DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++

  DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe bytes C++

  DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb bytes C++

  DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C

  DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C

it failed while calculate NPV(). 

So my questions is why setting the evaluation date to 09/18 for the discount term structure used for price engine didn't make any difference on price and what could be possible reason that the approach B failed. Your help will be greatly appreciated.

Best Regards,

Steve

On Fri, Oct 4, 2013 at 9:23 AM, Luigi Ballabio <[hidden email]> wrote:

Steve,
    just setting the evaluation date doesn't work because if you
specify a reference date for the curve, it overrides the evaluation
date.  For InterpolatedZeroCurve, that's done implicitly by using the
first passed date as reference date.  (For more info, see
<http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).

Now, there are solutions for this, but there are different possible
behaviors when moving the reference date (as you tried to do when
changing the evaluation date) and you'll have to choose the solution
based on the one you want.

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

If you want to move the whole thing two months ahead (that is, to have
discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
at 09/17/14 equal to the one you had at 07/31/14 before) you'll also
have to rebuild your data set and build a new curve.  For other types
of curves (not for InterpolatedZeroCurve, though) it's possible to
have this done automatically when the evaluation date changes; see the
link I've posted above.

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

Later,
    Luigi

On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
> Luiqi,
>
> Thank you for your help. I found one of the root problems. I used
> InterpolatedZeroCurve to return the corresponding Interpolation instance,
> given a set of data point dated between 07/31/12 and 07/31/14. However, I
> intended to set 09/19/12 as the settlement date and I did so in the program
> using Settings::instance().evaluationDate(). But I just found out that the
> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
> discount factors and in turn in clean and dirty prices. Please see the
> attachment for the program. I wonder why assigning Settings doesn't work. Do
> I need to define YieldTermStructure instance with a specified reference
> date?
>
> ===========setting evaluation date
> Natural settlementDays = 1;
> Integer fixingDays = 4;
>
> DayCounter DMCalcCounter = Actual360();
> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>
>    Date settlementDate(19, September, 2012);
>         // must be a business day
>         settlementDate = DMCalccalendar.adjust(settlementDate);
>
>         Date todaysDate = DMCalccalendar.advance(settlementDate,
> -fixingDays, Days);
> cout << "Today is " << todaysDate << endl;
>         // nothing to do with Date::todaysDate
>         Settings::instance().evaluationDate() = todaysDate;
>
> =============discount factor
> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
> 0 discount factor July 31st, 2012 ^^^ 1
>
>
>
>
>
> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> Steve,
>>     InterpolatedZeroCurve expects continuously compounded zero rates,
>> so the 0.00105 rate you're passing gets interpreted as such.  When you
>> later ask for the index fixing, the code calculates the corresponding
>> simply compounded rate, which is the 0.00105014 you're seeing (it's
>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>> to the correspondingly continuously compounded rate (same formula as
>> above, but inverted) and pass that one to the curve.
>>
>> However, this will work only as long as the rate is constant. If the
>> forecast index fixings vary in time, the zero rates will no longer be
>> the same as the index rates, even converting the compounding (the zero
>> rates are the average of the forward rates).  You'd be much better off
>> if your system could give you, for instance, sampled discount factors
>> at the same dates. Otherwise you'll have to figure out the zero rates
>> or the discount factors yourself.
>>
>> Hope this helps,
>>     Luigi
>>
>>
>>
>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> <[hidden email]> wrote:
>> > Steve,
>> >     may you send the data files you're using so that we can actually
>> > run your code?
>> >
>> > Luigi
>> >
>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>> >> Luigi,
>> >>
>> >> I tried to use IborIndex to price the floating note. The result is
>> >> about
>> >> 0.0036% off from the correct answer. There are many factors that
>> >> contribute
>> >> to this discrepancy. But I think the main reason is that the
>> >> forecastfixing
>> >> is about 0.013% off from the index rate. Below are the code printing
>> >> out
>> >> forecastfixing and some of the index rate:
>> >> for(int i=0;i<AccuralStart.size();i++){
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>> >> settlementDate){
>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i])
>> >> << "
>> >> +++ " << IndexRate[i] << endl;
>> >> }
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>> >> settlementDate){
>> >> junk << AccuralStart[i] << " ``` " <<
>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
>> >> endl;
>> >> }
>> >> }
>> >>
>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >>
>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>> >> rate
>> >> after the settlement date, Sept 19th, 2012, all the way to the maturity
>> >> date. Can you or anyone to help me to understand where 0.00000014 comes
>> >> from?
>> >>
>> >> Thanks
>> >>
>> >>
>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>> >>> > I am trying to price a floating rate bond that depends on the rate
>> >>> > of a
>> >>> > Treasury instrument. For simplicity, the rate and the date are
>> >>> > imported
>> >>> > from
>> >>> > the file. But I used IborIndex class for the rate of the instrument.
>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>> >>> > this
>> >>> > topic:
>> >>> >
>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>> >>> > like
>> >>> > IborIndex for LIBOR, in QuantLib?
>> >>>
>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>> >>> your Treasury instrument derived from that?  And instead of looking at
>> >>> the price of the bond (that is, at the sum of the coupons, which
>> >>> muddies things), have you tried first looking at forecast IborIndex
>> >>> fixings to see if they match the rates you expect?
>> >>>
>> >>> > 2 if the answer is no, is it possible to build a class like
>> >>> > TreasuryIndex by
>> >>> > extending InterestRateIndex? What would be the challenge in building
>> >>> > TreasuryIndex?
>> >>>
>> >>> You would have to implement the forecastFixing method so that it
>> >>> returns the T-Bill rate. Basically, you'd have to be able to forecast
>> >>> the rate off your treasury curve. (You'd also have to implement the
>> >>> maturityDate method, but that's easy).
>> >>>
>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>> >>> > tweaking
>> >>> > the
>> >>> > calendar alone? What else needs to be done to make it work?
>> >>>
>> >>> See above. It depends on how much the conventions differ.
>> >>>
>> >>> > 4      Can someone point me to the right direction on how to
>> >>> > leverage
>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>> >>> > instrument as the index after a peek at the code?
>> >>>
>> >>> If using IborIndex fails, inheriting from InterestRateIndex shouldn't
>> >>> be that difficult. Once you have a rate class, you should be able to
>> >>> use the existing classes as you did in your code.
>> >>>
>> >>> Let me know how it works.
>> >>>
>> >>> Later,
>> >>>     Luigi
>> >>>
>> >>>
>> >>> --
>> >>> <https://implementingquantlib.blogspot.com>
>> >>> <https://twitter.com/lballabio>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > <https://implementingquantlib.blogspot.com>
>> > <https://twitter.com/lballabio>
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>



--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[hudsoncity]

Luigi, 

Thank you very much for your time and help!

/////    approach A

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

//////

I use two yield term structure. TB13WksRateTermStructure, basically is the zero rate of original file whose evaluation date is 7/31 because the original file starts with 7/31/12. Then I use ImpliedTermStructure to set the evaluation date to 09/18 to create another yield term structure, discountRateTermStructureImplied. TB13WksRateTermStructure is the input for FloatingRateBond FRN and discountRateTermStructureImplied is linked to FRNEngine. But the result, dirty/clean price turns out to be the same as before the evaluation date of the yield term structured used for the engine was set to 09/18/12. Any way, it doesn't make difference on the price.

////////           Approach B

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

////////////

I remove the data before 09/18/12 from both the index file and the accrual date file. But the program errored out with 

AccuralStartSize = 680

IndexRateFileSize = 680

negative time (-0.0111111) given

I tried to locate where exactly the program failed. The closest I could get is

> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++

  DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++

  DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe bytes C++

  DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb bytes C++

  DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C

  DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C

it failed while calculate NPV(). 

So my questions is why setting the evaluation date to 09/18 for the discount term structure used for price engine didn't make any difference on price and what could be possible reason that the approach B failed. Your help will be greatly appreciated.

Best Regards,

Steve

From: Luigi Ballabio <[hidden email]>
To: Steve <[hidden email]>
Cc: QuantLib users <[hidden email]>
Sent: Friday, October 4, 2013 9:23 AM
Subject: Re: [Quantlib-users] pricing a floating rate bond

Steve,
    just setting the evaluation date doesn&apos;t work because if you
specify a reference date for the curve, it overrides the evaluation
date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
first passed date as reference date.  (For more info, see
<http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).

Now, there are solutions for this, but there are different possible
behaviors when moving the reference date (as you tried to do when
changing the evaluation date) and you&apos;ll have to choose the solution
based on the one you want.

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you&apos;ll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

If you want to move the whole thing two months ahead (that is, to have
discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
have to rebuild your data set and build a new curve.  For other types
of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
have this done automatically when the evaluation date changes; see the
link I&apos;ve posted above.

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

Later,
    Luigi


On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:

> Luiqi,
>
> Thank you for your help. I found one of the root problems. I used
> InterpolatedZeroCurve to return the corresponding Interpolation instance,
> given a set of data point dated between 07/31/12 and 07/31/14. However, I
> intended to set 09/19/12 as the settlement date and I did so in the program
> using Settings::instance().evaluationDate(). But I just found out that the
> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
> discount factors and in turn in clean and dirty prices. Please see the
> attachment for the program. I wonder why assigning Settings doesn&apos;t work. Do
> I need to define YieldTermStructure instance with a specified reference
> date?
>
> ===========setting evaluation date
> Natural settlementDays = 1;
> Integer fixingDays = 4;
>
> DayCounter DMCalcCounter = Actual360();
> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>
>    Date settlementDate(19, September, 2012);
>        // must be a business day
>        settlementDate = DMCalccalendar.adjust(settlementDate);
>
>        Date todaysDate = DMCalccalendar.advance(settlementDate,
> -fixingDays, Days);
> cout << "Today is " << todaysDate << endl;
>        // nothing to do with Date::todaysDate
>        Settings::instance().evaluationDate() = todaysDate;
>
> =============discount factor
> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
> 0 discount factor July 31st, 2012 ^^^ 1
>
>
>
>
>
> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> Steve,
>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When you
>> later ask for the index fixing, the code calculates the corresponding
>> simply compounded rate, which is the 0.00105014 you&apos;re seeing (it&apos;s
>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>> to the correspondingly continuously compounded rate (same formula as
>> above, but inverted) and pass that one to the curve.
>>
>> However, this will work only as long as the rate is constant. If the
>> forecast index fixings vary in time, the zero rates will no longer be
>> the same as the index rates, even converting the compounding (the zero
>> rates are the average of the forward rates).  You&apos;d be much better off
>> if your system could give you, for instance, sampled discount factors
>> at the same dates. Otherwise you&apos;ll have to figure out the zero rates
>> or the discount factors yourself.
>>
>> Hope this helps,
>>    Luigi
>>
>>
>>
>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> <[hidden email]> wrote:
>> > Steve,
>> >    may you send the data files you&apos;re using so that we can actually
>> > run your code?
>> >
>> > Luigi
>> >
>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>> >> Luigi,
>> >>
>> >> I tried to use IborIndex to price the floating note. The result is
>> >> about
>> >> 0.0036% off from the correct answer. There are many factors that
>> >> contribute
>> >> to this discrepancy. But I think the main reason is that the
>> >> forecastfixing
>> >> is about 0.013% off from the index rate. Below are the code printing
>> >> out
>> >> forecastfixing and some of the index rate:
>> >> for(int i=0;i<AccuralStart.size();i++){
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>> >> settlementDate){
>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >> junk << AccuralStart[i] << " +++ " << FRN13Wks->fixing(AccuralStart[i])
>> >> << "
>> >> +++ " << IndexRate[i] << endl;
>> >> }
>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>> >> settlementDate){
>> >> junk << AccuralStart[i] << " ``` " <<
>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i] <<
>> >> endl;
>> >> }
>> >> }
>> >>
>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >>
>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>> >> rate
>> >> after the settlement date, Sept 19th, 2012, all the way to the maturity
>> >> date. Can you or anyone to help me to understand where 0.00000014 comes
>> >> from?
>> >>
>> >> Thanks
>> >>
>> >>
>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>> >>> > I am trying to price a floating rate bond that depends on the rate
>> >>> > of a
>> >>> > Treasury instrument. For simplicity, the rate and the date are
>> >>> > imported
>> >>> > from
>> >>> > the file. But I used IborIndex class for the rate of the instrument.
>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>> >>> > this
>> >>> > topic:
>> >>> >
>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>> >>> > like
>> >>> > IborIndex for LIBOR, in QuantLib?
>> >>>
>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>> >>> your Treasury instrument derived from that?  And instead of looking at
>> >>> the price of the bond (that is, at the sum of the coupons, which
>> >>> muddies things), have you tried first looking at forecast IborIndex
>> >>> fixings to see if they match the rates you expect?
>> >>>
>> >>> > 2 if the answer is no, is it possible to build a class like
>> >>> > TreasuryIndex by
>> >>> > extending InterestRateIndex? What would be the challenge in building
>> >>> > TreasuryIndex?
>> >>>
>> >>> You would have to implement the forecastFixing method so that it
>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to forecast
>> >>> the rate off your treasury curve. (You&apos;d also have to implement the
>> >>> maturityDate method, but that&apos;s easy).
>> >>>
>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>> >>> > tweaking
>> >>> > the
>> >>> > calendar alone? What else needs to be done to make it work?
>> >>>
>> >>> See above. It depends on how much the conventions differ.
>> >>>
>> >>> > 4      Can someone point me to the right direction on how to
>> >>> > leverage
>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>> >>> > instrument as the index after a peek at the code?
>> >>>
>> >>> If using IborIndex fails, inheriting from InterestRateIndex shouldn&apos;t
>> >>> be that difficult. Once you have a rate class, you should be able to
>> >>> use the existing classes as you did in your code.
>> >>>
>> >>> Let me know how it works.
>> >>>
>> >>> Later,
>> >>>    Luigi
>> >>>
>> >>>
>> >>> --
>> >>> <https://implementingquantlib.blogspot.com/>
>> >>> <https://twitter.com/lballabio>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > <https://implementingquantlib.blogspot.com/>
>> > <https://twitter.com/lballabio>
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com/>
>> <https://twitter.com/lballabio>
>
>

--
<https://implementingquantlib.blogspot.com/>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk

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

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Can you post a minimal program to replicate this?

Luigi

On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:

> Luigi,
>
> Thank you very much for your time and help!
>
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
> I use two yield term structure. TB13WksRateTermStructure, basically is the
> zero rate of original file whose evaluation date is 7/31 because the
> original file starts with 7/31/12. Then I use ImpliedTermStructure to set
> the evaluation date to 09/18 to create another yield term structure,
> discountRateTermStructureImplied. TB13WksRateTermStructure is the input for
> FloatingRateBond FRN and discountRateTermStructureImplied is linked to
> FRNEngine. But the result, dirty/clean price turns out to be the same as
> before the evaluation date of the yield term structured used for the engine
> was set to 09/18/12. Any way, it doesn't make difference on the price.
>
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
> I remove the data before 09/18/12 from both the index file and the accrual
> date file. But the program errored out with
> AccuralStartSize = 680
> IndexRateFileSize = 680
> negative time (-0.0111111) given
>
> I tried to locate where exactly the program failed. The closest I could get
> is
>> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe
> bytes C++
>   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb
> bytes C++
>   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
>   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
> it failed while calculate NPV().
>
> So my questions is why setting the evaluation date to 09/18 for the discount
> term structure used for price engine didn't make any difference on price and
> what could be possible reason that the approach B failed. Your help will be
> greatly appreciated.
>
> Best Regards,
> Steve
>
>
> From: Luigi Ballabio <[hidden email]>
> To: Steve <[hidden email]>
> Cc: QuantLib users <[hidden email]>
> Sent: Friday, October 4, 2013 9:23 AM
> Subject: Re: [Quantlib-users] pricing a floating rate bond
>
> Steve,
>     just setting the evaluation date doesn&apos;t work because if you
>
> specify a reference date for the curve, it overrides the evaluation
> date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
>
> first passed date as reference date.  (For more info, see
> <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>
> Now, there are solutions for this, but there are different possible
> behaviors when moving the reference date (as you tried to do when
> changing the evaluation date) and you&apos;ll have to choose the solution
>
> based on the one you want.
>
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you&apos;ll have to rebuild your
>
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
>
> If you want to move the whole thing two months ahead (that is, to have
> discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
> at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
>
> have to rebuild your data set and build a new curve.  For other types
> of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
>
> have this done automatically when the evaluation date changes; see the
> link I&apos;ve posted above.
>
>
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
>
> Later,
>     Luigi
>
>
> On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> Luiqi,
>>
>> Thank you for your help. I found one of the root problems. I used
>> InterpolatedZeroCurve to return the corresponding Interpolation instance,
>> given a set of data point dated between 07/31/12 and 07/31/14. However, I
>> intended to set 09/19/12 as the settlement date and I did so in the
>> program
>> using Settings::instance().evaluationDate(). But I just found out that the
>> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>> discount factors and in turn in clean and dirty prices. Please see the
>> attachment for the program. I wonder why assigning Settings doesn&apos;t
>> work. Do
>
>> I need to define YieldTermStructure instance with a specified reference
>> date?
>>
>> ===========setting evaluation date
>> Natural settlementDays = 1;
>> Integer fixingDays = 4;
>>
>> DayCounter DMCalcCounter = Actual360();
>> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>
>>    Date settlementDate(19, September, 2012);
>>        // must be a business day
>>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>
>>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> -fixingDays, Days);
>> cout << "Today is " << todaysDate << endl;
>>        // nothing to do with Date::todaysDate
>>        Settings::instance().evaluationDate() = todaysDate;
>>
>> =============discount factor
>> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
>> 0 discount factor July 31st, 2012 ^^^ 1
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> Steve,
>>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When
>>> you
>
>>> later ask for the index fixing, the code calculates the corresponding
>>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>> (it&apos;s
>
>>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>> to the correspondingly continuously compounded rate (same formula as
>>> above, but inverted) and pass that one to the curve.
>>>
>>> However, this will work only as long as the rate is constant. If the
>>> forecast index fixings vary in time, the zero rates will no longer be
>>> the same as the index rates, even converting the compounding (the zero
>>> rates are the average of the forward rates).  You&apos;d be much better
>>> off
>
>>> if your system could give you, for instance, sampled discount factors
>>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>> rates
>
>>> or the discount factors yourself.
>>>
>>> Hope this helps,
>>>    Luigi
>>>
>>>
>>>
>>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>> <[hidden email]> wrote:
>>> > Steve,
>>> >    may you send the data files you&apos;re using so that we can
>>> > actually
>
>>> > run your code?
>>> >
>>> > Luigi
>>> >
>>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>> >> Luigi,
>>> >>
>>> >> I tried to use IborIndex to price the floating note. The result is
>>> >> about
>>> >> 0.0036% off from the correct answer. There are many factors that
>>> >> contribute
>>> >> to this discrepancy. But I think the main reason is that the
>>> >> forecastfixing
>>> >> is about 0.013% off from the index rate. Below are the code printing
>>> >> out
>>> >> forecastfixing and some of the index rate:
>>> >> for(int i=0;i<AccuralStart.size();i++){
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>>> >> settlementDate){
>>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>> >> junk << AccuralStart[i] << " +++ " <<
>>> >> FRN13Wks->fixing(AccuralStart[i])
>>> >> << "
>>> >> +++ " << IndexRate[i] << endl;
>>> >> }
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>>> >> settlementDate){
>>> >> junk << AccuralStart[i] << " ``` " <<
>>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i]
>>> >> <<
>>> >> endl;
>>> >> }
>>> >> }
>>> >>
>>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>> >>
>>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>>> >> rate
>>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>> >> maturity
>>> >> date. Can you or anyone to help me to understand where 0.00000014
>>> >> comes
>>> >> from?
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> >>> > I am trying to price a floating rate bond that depends on the rate
>>> >>> > of a
>>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>> >>> > imported
>>> >>> > from
>>> >>> > the file. But I used IborIndex class for the rate of the
>>> >>> > instrument.
>>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>>> >>> > this
>>> >>> > topic:
>>> >>> >
>>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>>> >>> > like
>>> >>> > IborIndex for LIBOR, in QuantLib?
>>> >>>
>>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> >>> your Treasury instrument derived from that?  And instead of looking
>>> >>> at
>>> >>> the price of the bond (that is, at the sum of the coupons, which
>>> >>> muddies things), have you tried first looking at forecast IborIndex
>>> >>> fixings to see if they match the rates you expect?
>>> >>>
>>> >>> > 2 if the answer is no, is it possible to build a class like
>>> >>> > TreasuryIndex by
>>> >>> > extending InterestRateIndex? What would be the challenge in
>>> >>> > building
>>> >>> > TreasuryIndex?
>>> >>>
>>> >>> You would have to implement the forecastFixing method so that it
>>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to
>>> >>> forecast
>>> >>> the rate off your treasury curve. (You&apos;d also have to implement
>>> >>> the
>>> >>> maturityDate method, but that&apos;s easy).
>
>>> >>>
>>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>> >>> > tweaking
>>> >>> > the
>>> >>> > calendar alone? What else needs to be done to make it work?
>>> >>>
>>> >>> See above. It depends on how much the conventions differ.
>>> >>>
>>> >>> > 4      Can someone point me to the right direction on how to
>>> >>> > leverage
>>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> >>> > instrument as the index after a peek at the code?
>>> >>>
>>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>> >>> shouldn&apos;t
>
>>> >>> be that difficult. Once you have a rate class, you should be able to
>>> >>> use the existing classes as you did in your code.
>>> >>>
>>> >>> Let me know how it works.
>>> >>>
>>> >>> Later,
>>> >>>    Luigi
>>> >>>
>>> >>>
>>> >>> --
>>> >>> <https://implementingquantlib.blogspot.com/>
>>> >>> <https://twitter.com/lballabio>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > <https://implementingquantlib.blogspot.com/>
>>> > <https://twitter.com/lballabio>
>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com/>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com/>
> <https://twitter.com/lballabio>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Thank you Lugi. I will get back to you tomorrow.

On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]> wrote:

Can you post a minimal program to replicate this?

Luigi

On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
> Luigi,
>
> Thank you very much for your time and help!
>
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
> I use two yield term structure. TB13WksRateTermStructure, basically is the
> zero rate of original file whose evaluation date is 7/31 because the
> original file starts with 7/31/12. Then I use ImpliedTermStructure to set
> the evaluation date to 09/18 to create another yield term structure,
> discountRateTermStructureImplied. TB13WksRateTermStructure is the input for
> FloatingRateBond FRN and discountRateTermStructureImplied is linked to
> FRNEngine. But the result, dirty/clean price turns out to be the same as
> before the evaluation date of the yield term structured used for the engine
> was set to 09/18/12. Any way, it doesn't make difference on the price.
>
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
> I remove the data before 09/18/12 from both the index file and the accrual
> date file. But the program errored out with
> AccuralStartSize = 680
> IndexRateFileSize = 680
> negative time (-0.0111111) given
>
> I tried to locate where exactly the program failed. The closest I could get
> is
>> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe
> bytes C++
>   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb
> bytes C++
>   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
>   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
> it failed while calculate NPV().
>
> So my questions is why setting the evaluation date to 09/18 for the discount
> term structure used for price engine didn't make any difference on price and
> what could be possible reason that the approach B failed. Your help will be
> greatly appreciated.
>
> Best Regards,
> Steve
>
>
> From: Luigi Ballabio <[hidden email]>
> To: Steve <[hidden email]>
> Cc: QuantLib users <[hidden email]>
> Sent: Friday, October 4, 2013 9:23 AM
> Subject: Re: [Quantlib-users] pricing a floating rate bond
>
> Steve,
>     just setting the evaluation date doesn&apos;t work because if you
>
> specify a reference date for the curve, it overrides the evaluation
> date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
>
> first passed date as reference date.  (For more info, see
> <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>
> Now, there are solutions for this, but there are different possible
> behaviors when moving the reference date (as you tried to do when
> changing the evaluation date) and you&apos;ll have to choose the solution
>
> based on the one you want.
>
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you&apos;ll have to rebuild your
>
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
>
> If you want to move the whole thing two months ahead (that is, to have
> discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
> at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
>
> have to rebuild your data set and build a new curve.  For other types
> of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
>
> have this done automatically when the evaluation date changes; see the
> link I&apos;ve posted above.
>
>
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
>
> Later,
>     Luigi
>
>
> On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> Luiqi,
>>
>> Thank you for your help. I found one of the root problems. I used
>> InterpolatedZeroCurve to return the corresponding Interpolation instance,
>> given a set of data point dated between 07/31/12 and 07/31/14. However, I
>> intended to set 09/19/12 as the settlement date and I did so in the
>> program
>> using Settings::instance().evaluationDate(). But I just found out that the
>> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>> discount factors and in turn in clean and dirty prices. Please see the
>> attachment for the program. I wonder why assigning Settings doesn&apos;t
>> work. Do
>
>> I need to define YieldTermStructure instance with a specified reference
>> date?
>>
>> ===========setting evaluation date
>> Natural settlementDays = 1;
>> Integer fixingDays = 4;
>>
>> DayCounter DMCalcCounter = Actual360();
>> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>
>>    Date settlementDate(19, September, 2012);
>>        // must be a business day
>>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>
>>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> -fixingDays, Days);
>> cout << "Today is " << todaysDate << endl;
>>        // nothing to do with Date::todaysDate
>>        Settings::instance().evaluationDate() = todaysDate;
>>
>> =============discount factor
>> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
>> 0 discount factor July 31st, 2012 ^^^ 1
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> Steve,
>>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When
>>> you
>
>>> later ask for the index fixing, the code calculates the corresponding
>>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>> (it&apos;s
>
>>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>> to the correspondingly continuously compounded rate (same formula as
>>> above, but inverted) and pass that one to the curve.
>>>
>>> However, this will work only as long as the rate is constant. If the
>>> forecast index fixings vary in time, the zero rates will no longer be
>>> the same as the index rates, even converting the compounding (the zero
>>> rates are the average of the forward rates).  You&apos;d be much better
>>> off
>
>>> if your system could give you, for instance, sampled discount factors
>>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>> rates
>
>>> or the discount factors yourself.
>>>
>>> Hope this helps,
>>>    Luigi
>>>
>>>
>>>
>>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>> <[hidden email]> wrote:
>>> > Steve,
>>> >    may you send the data files you&apos;re using so that we can
>>> > actually
>
>>> > run your code?
>>> >
>>> > Luigi
>>> >
>>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>> >> Luigi,
>>> >>
>>> >> I tried to use IborIndex to price the floating note. The result is
>>> >> about
>>> >> 0.0036% off from the correct answer. There are many factors that
>>> >> contribute
>>> >> to this discrepancy. But I think the main reason is that the
>>> >> forecastfixing
>>> >> is about 0.013% off from the index rate. Below are the code printing
>>> >> out
>>> >> forecastfixing and some of the index rate:
>>> >> for(int i=0;i<AccuralStart.size();i++){
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>>> >> settlementDate){
>>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>> >> junk << AccuralStart[i] << " +++ " <<
>>> >> FRN13Wks->fixing(AccuralStart[i])
>>> >> << "
>>> >> +++ " << IndexRate[i] << endl;
>>> >> }
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>>> >> settlementDate){
>>> >> junk << AccuralStart[i] << " ``` " <<
>>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i]
>>> >> <<
>>> >> endl;
>>> >> }
>>> >> }
>>> >>
>>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>> >>
>>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>>> >> rate
>>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>> >> maturity
>>> >> date. Can you or anyone to help me to understand where 0.00000014
>>> >> comes
>>> >> from?
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> >>> > I am trying to price a floating rate bond that depends on the rate
>>> >>> > of a
>>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>> >>> > imported
>>> >>> > from
>>> >>> > the file. But I used IborIndex class for the rate of the
>>> >>> > instrument.
>>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>>> >>> > this
>>> >>> > topic:
>>> >>> >
>>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>>> >>> > like
>>> >>> > IborIndex for LIBOR, in QuantLib?
>>> >>>
>>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> >>> your Treasury instrument derived from that?  And instead of looking
>>> >>> at
>>> >>> the price of the bond (that is, at the sum of the coupons, which
>>> >>> muddies things), have you tried first looking at forecast IborIndex
>>> >>> fixings to see if they match the rates you expect?
>>> >>>
>>> >>> > 2 if the answer is no, is it possible to build a class like
>>> >>> > TreasuryIndex by
>>> >>> > extending InterestRateIndex? What would be the challenge in
>>> >>> > building
>>> >>> > TreasuryIndex?
>>> >>>
>>> >>> You would have to implement the forecastFixing method so that it
>>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to
>>> >>> forecast
>>> >>> the rate off your treasury curve. (You&apos;d also have to implement
>>> >>> the
>>> >>> maturityDate method, but that&apos;s easy).
>
>>> >>>
>>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>> >>> > tweaking
>>> >>> > the
>>> >>> > calendar alone? What else needs to be done to make it work?
>>> >>>
>>> >>> See above. It depends on how much the conventions differ.
>>> >>>
>>> >>> > 4      Can someone point me to the right direction on how to
>>> >>> > leverage
>>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> >>> > instrument as the index after a peek at the code?
>>> >>>
>>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>> >>> shouldn&apos;t
>
>>> >>> be that difficult. Once you have a rate class, you should be able to
>>> >>> use the existing classes as you did in your code.
>>> >>>
>>> >>> Let me know how it works.
>>> >>>
>>> >>> Later,
>>> >>>    Luigi
>>> >>>
>>> >>>
>>> >>> --
>>> >>> <https://implementingquantlib.blogspot.com/>
>>> >>> <https://twitter.com/lballabio>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > <https://implementingquantlib.blogspot.com/>
>>> > <https://twitter.com/lballabio>
>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com/>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com/>
> <https://twitter.com/lballabio>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luigi,

I was not able to make the program much smaller than it used to be. I simply removed the printing sections. I divided the code to two programs, one for the approach A and the other for the approach B. They are almost identical except that the approach B uses ASDateOriginal.dat and IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and use ImpliedTermStructure to set evaluation date for term structure used by floating rate note price engine to 09/13/12. Somehow, resetting the evaluation date doesn't make any difference in the result

In the approach A, the program use 07/01/12 as the evaluation date for TB13WksRateTermStructure that is the input when calling FloatingRateBond FRN(...). the evaluation date for discountRateTermStructureImplied that is used in FRN.setPricingEngine. Actually, I am not sure that index structure in FRN and the term structure used in its price engine can have two different evaluation date. this approach erred out with 'negative time (-0.0111111) given'

the program for A and B attached. also the data file for A and B are attached. B uses *original* files

Thank you!

On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]> wrote:

Can you post a minimal program to replicate this?

Luigi

On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
> Luigi,
>
> Thank you very much for your time and help!
>
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
> I use two yield term structure. TB13WksRateTermStructure, basically is the
> zero rate of original file whose evaluation date is 7/31 because the
> original file starts with 7/31/12. Then I use ImpliedTermStructure to set
> the evaluation date to 09/18 to create another yield term structure,
> discountRateTermStructureImplied. TB13WksRateTermStructure is the input for
> FloatingRateBond FRN and discountRateTermStructureImplied is linked to
> FRNEngine. But the result, dirty/clean price turns out to be the same as
> before the evaluation date of the yield term structured used for the engine
> was set to 09/18/12. Any way, it doesn't make difference on the price.
>
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
> I remove the data before 09/18/12 from both the index file and the accrual
> date file. But the program errored out with
> AccuralStartSize = 680
> IndexRateFileSize = 680
> negative time (-0.0111111) given
>
> I tried to locate where exactly the program failed. The closest I could get
> is
>> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe
> bytes C++
>   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb
> bytes C++
>   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
>   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
> it failed while calculate NPV().
>
> So my questions is why setting the evaluation date to 09/18 for the discount
> term structure used for price engine didn't make any difference on price and
> what could be possible reason that the approach B failed. Your help will be
> greatly appreciated.
>
> Best Regards,
> Steve
>
>
> From: Luigi Ballabio <[hidden email]>
> To: Steve <[hidden email]>
> Cc: QuantLib users <[hidden email]>
> Sent: Friday, October 4, 2013 9:23 AM
> Subject: Re: [Quantlib-users] pricing a floating rate bond
>
> Steve,
>     just setting the evaluation date doesn&apos;t work because if you
>
> specify a reference date for the curve, it overrides the evaluation
> date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
>
> first passed date as reference date.  (For more info, see
> <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>
> Now, there are solutions for this, but there are different possible
> behaviors when moving the reference date (as you tried to do when
> changing the evaluation date) and you&apos;ll have to choose the solution
>
> based on the one you want.
>
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you&apos;ll have to rebuild your
>
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
>
> If you want to move the whole thing two months ahead (that is, to have
> discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
> at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
>
> have to rebuild your data set and build a new curve.  For other types
> of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
>
> have this done automatically when the evaluation date changes; see the
> link I&apos;ve posted above.
>
>
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
>
> Later,
>     Luigi
>
>
> On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> Luiqi,
>>
>> Thank you for your help. I found one of the root problems. I used
>> InterpolatedZeroCurve to return the corresponding Interpolation instance,
>> given a set of data point dated between 07/31/12 and 07/31/14. However, I
>> intended to set 09/19/12 as the settlement date and I did so in the
>> program
>> using Settings::instance().evaluationDate(). But I just found out that the
>> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>> discount factors and in turn in clean and dirty prices. Please see the
>> attachment for the program. I wonder why assigning Settings doesn&apos;t
>> work. Do
>
>> I need to define YieldTermStructure instance with a specified reference
>> date?
>>
>> ===========setting evaluation date
>> Natural settlementDays = 1;
>> Integer fixingDays = 4;
>>
>> DayCounter DMCalcCounter = Actual360();
>> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>
>>    Date settlementDate(19, September, 2012);
>>        // must be a business day
>>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>
>>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> -fixingDays, Days);
>> cout << "Today is " << todaysDate << endl;
>>        // nothing to do with Date::todaysDate
>>        Settings::instance().evaluationDate() = todaysDate;
>>
>> =============discount factor
>> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
>> 0 discount factor July 31st, 2012 ^^^ 1
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> Steve,
>>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When
>>> you
>
>>> later ask for the index fixing, the code calculates the corresponding
>>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>> (it&apos;s
>
>>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>> to the correspondingly continuously compounded rate (same formula as
>>> above, but inverted) and pass that one to the curve.
>>>
>>> However, this will work only as long as the rate is constant. If the
>>> forecast index fixings vary in time, the zero rates will no longer be
>>> the same as the index rates, even converting the compounding (the zero
>>> rates are the average of the forward rates).  You&apos;d be much better
>>> off
>
>>> if your system could give you, for instance, sampled discount factors
>>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>> rates
>
>>> or the discount factors yourself.
>>>
>>> Hope this helps,
>>>    Luigi
>>>
>>>
>>>
>>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>> <[hidden email]> wrote:
>>> > Steve,
>>> >    may you send the data files you&apos;re using so that we can
>>> > actually
>
>>> > run your code?
>>> >
>>> > Luigi
>>> >
>>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>> >> Luigi,
>>> >>
>>> >> I tried to use IborIndex to price the floating note. The result is
>>> >> about
>>> >> 0.0036% off from the correct answer. There are many factors that
>>> >> contribute
>>> >> to this discrepancy. But I think the main reason is that the
>>> >> forecastfixing
>>> >> is about 0.013% off from the index rate. Below are the code printing
>>> >> out
>>> >> forecastfixing and some of the index rate:
>>> >> for(int i=0;i<AccuralStart.size();i++){
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>>> >> settlementDate){
>>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>> >> junk << AccuralStart[i] << " +++ " <<
>>> >> FRN13Wks->fixing(AccuralStart[i])
>>> >> << "
>>> >> +++ " << IndexRate[i] << endl;
>>> >> }
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>>> >> settlementDate){
>>> >> junk << AccuralStart[i] << " ``` " <<
>>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i]
>>> >> <<
>>> >> endl;
>>> >> }
>>> >> }
>>> >>
>>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>> >>
>>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>>> >> rate
>>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>> >> maturity
>>> >> date. Can you or anyone to help me to understand where 0.00000014
>>> >> comes
>>> >> from?
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> >>> > I am trying to price a floating rate bond that depends on the rate
>>> >>> > of a
>>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>> >>> > imported
>>> >>> > from
>>> >>> > the file. But I used IborIndex class for the rate of the
>>> >>> > instrument.
>>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>>> >>> > this
>>> >>> > topic:
>>> >>> >
>>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>>> >>> > like
>>> >>> > IborIndex for LIBOR, in QuantLib?
>>> >>>
>>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> >>> your Treasury instrument derived from that?  And instead of looking
>>> >>> at
>>> >>> the price of the bond (that is, at the sum of the coupons, which
>>> >>> muddies things), have you tried first looking at forecast IborIndex
>>> >>> fixings to see if they match the rates you expect?
>>> >>>
>>> >>> > 2 if the answer is no, is it possible to build a class like
>>> >>> > TreasuryIndex by
>>> >>> > extending InterestRateIndex? What would be the challenge in
>>> >>> > building
>>> >>> > TreasuryIndex?
>>> >>>
>>> >>> You would have to implement the forecastFixing method so that it
>>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to
>>> >>> forecast
>>> >>> the rate off your treasury curve. (You&apos;d also have to implement
>>> >>> the
>>> >>> maturityDate method, but that&apos;s easy).
>
>>> >>>
>>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>> >>> > tweaking
>>> >>> > the
>>> >>> > calendar alone? What else needs to be done to make it work?
>>> >>>
>>> >>> See above. It depends on how much the conventions differ.
>>> >>>
>>> >>> > 4      Can someone point me to the right direction on how to
>>> >>> > leverage
>>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> >>> > instrument as the index after a peek at the code?
>>> >>>
>>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>> >>> shouldn&apos;t
>
>>> >>> be that difficult. Once you have a rate class, you should be able to
>>> >>> use the existing classes as you did in your code.
>>> >>>
>>> >>> Let me know how it works.
>>> >>>
>>> >>> Later,
>>> >>>    Luigi
>>> >>>
>>> >>>
>>> >>> --
>>> >>> <https://implementingquantlib.blogspot.com/>
>>> >>> <https://twitter.com/lballabio>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > <https://implementingquantlib.blogspot.com/>
>>> > <https://twitter.com/lballabio>
>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com/>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com/>
> <https://twitter.com/lballabio>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

more on approach B

////////           Approach B

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

////////////

the program will not error out with 'egative time (-0.0111111) given' and give some result after the first date in the input index rate file was moved from 09/18 to 09/13. But it is not right, because the discount factor should be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to the fact that the interested start to accrue on 09/13 not 09/18, thought the discount factor should be 1 on 09/18. This is because the instrument used for index rate is issued every Thursday.  So the dilemma is that the date when the interest accrual starts and the date where discount factor equals to 1 are different! That only invalidate the approach B. But I would think someone must have dealt this kind of dilemma long ago. 

On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:

Luigi,

I was not able to make the program much smaller than it used to be. I simply removed the printing sections. I divided the code to two programs, one for the approach A and the other for the approach B. They are almost identical except that the approach B uses ASDateOriginal.dat and IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and use ImpliedTermStructure to set evaluation date for term structure used by floating rate note price engine to 09/13/12. Somehow, resetting the evaluation date doesn't make any difference in the result

In the approach A, the program use 07/01/12 as the evaluation date for TB13WksRateTermStructure that is the input when calling FloatingRateBond FRN(...). the evaluation date for discountRateTermStructureImplied that is used in FRN.setPricingEngine. Actually, I am not sure that index structure in FRN and the term structure used in its price engine can have two different evaluation date. this approach erred out with 'negative time (-0.0111111) given'

the program for A and B attached. also the data file for A and B are attached. B uses *original* files

Thank you!

On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]> wrote:

Can you post a minimal program to replicate this?

Luigi

On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
> Luigi,
>
> Thank you very much for your time and help!
>
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
> I use two yield term structure. TB13WksRateTermStructure, basically is the
> zero rate of original file whose evaluation date is 7/31 because the
> original file starts with 7/31/12. Then I use ImpliedTermStructure to set
> the evaluation date to 09/18 to create another yield term structure,
> discountRateTermStructureImplied. TB13WksRateTermStructure is the input for
> FloatingRateBond FRN and discountRateTermStructureImplied is linked to
> FRNEngine. But the result, dirty/clean price turns out to be the same as
> before the evaluation date of the yield term structured used for the engine
> was set to 09/18/12. Any way, it doesn't make difference on the price.
>
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
> I remove the data before 09/18/12 from both the index file and the accrual
> date file. But the program errored out with
> AccuralStartSize = 680
> IndexRateFileSize = 680
> negative time (-0.0111111) given
>
> I tried to locate where exactly the program failed. The closest I could get
> is
>> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe
> bytes C++
>   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb
> bytes C++
>   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
>   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
> it failed while calculate NPV().
>
> So my questions is why setting the evaluation date to 09/18 for the discount
> term structure used for price engine didn't make any difference on price and
> what could be possible reason that the approach B failed. Your help will be
> greatly appreciated.
>
> Best Regards,
> Steve
>
>
> From: Luigi Ballabio <[hidden email]>
> To: Steve <[hidden email]>
> Cc: QuantLib users <[hidden email]>
> Sent: Friday, October 4, 2013 9:23 AM
> Subject: Re: [Quantlib-users] pricing a floating rate bond
>
> Steve,
>     just setting the evaluation date doesn&apos;t work because if you
>
> specify a reference date for the curve, it overrides the evaluation
> date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
>
> first passed date as reference date.  (For more info, see
> <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>
> Now, there are solutions for this, but there are different possible
> behaviors when moving the reference date (as you tried to do when
> changing the evaluation date) and you&apos;ll have to choose the solution
>
> based on the one you want.
>
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you&apos;ll have to rebuild your
>
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
>
> If you want to move the whole thing two months ahead (that is, to have
> discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
> at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
>
> have to rebuild your data set and build a new curve.  For other types
> of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
>
> have this done automatically when the evaluation date changes; see the
> link I&apos;ve posted above.
>
>
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
>
> Later,
>     Luigi
>
>
> On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> Luiqi,
>>
>> Thank you for your help. I found one of the root problems. I used
>> InterpolatedZeroCurve to return the corresponding Interpolation instance,
>> given a set of data point dated between 07/31/12 and 07/31/14. However, I
>> intended to set 09/19/12 as the settlement date and I did so in the
>> program
>> using Settings::instance().evaluationDate(). But I just found out that the
>> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>> discount factors and in turn in clean and dirty prices. Please see the
>> attachment for the program. I wonder why assigning Settings doesn&apos;t
>> work. Do
>
>> I need to define YieldTermStructure instance with a specified reference
>> date?
>>
>> ===========setting evaluation date
>> Natural settlementDays = 1;
>> Integer fixingDays = 4;
>>
>> DayCounter DMCalcCounter = Actual360();
>> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>
>>    Date settlementDate(19, September, 2012);
>>        // must be a business day
>>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>
>>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> -fixingDays, Days);
>> cout << "Today is " << todaysDate << endl;
>>        // nothing to do with Date::todaysDate
>>        Settings::instance().evaluationDate() = todaysDate;
>>
>> =============discount factor
>> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
>> 0 discount factor July 31st, 2012 ^^^ 1
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> Steve,
>>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When
>>> you
>
>>> later ask for the index fixing, the code calculates the corresponding
>>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>> (it&apos;s
>
>>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>> to the correspondingly continuously compounded rate (same formula as
>>> above, but inverted) and pass that one to the curve.
>>>
>>> However, this will work only as long as the rate is constant. If the
>>> forecast index fixings vary in time, the zero rates will no longer be
>>> the same as the index rates, even converting the compounding (the zero
>>> rates are the average of the forward rates).  You&apos;d be much better
>>> off
>
>>> if your system could give you, for instance, sampled discount factors
>>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>> rates
>
>>> or the discount factors yourself.
>>>
>>> Hope this helps,
>>>    Luigi
>>>
>>>
>>>
>>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>> <[hidden email]> wrote:
>>> > Steve,
>>> >    may you send the data files you&apos;re using so that we can
>>> > actually
>
>>> > run your code?
>>> >
>>> > Luigi
>>> >
>>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>> >> Luigi,
>>> >>
>>> >> I tried to use IborIndex to price the floating note. The result is
>>> >> about
>>> >> 0.0036% off from the correct answer. There are many factors that
>>> >> contribute
>>> >> to this discrepancy. But I think the main reason is that the
>>> >> forecastfixing
>>> >> is about 0.013% off from the index rate. Below are the code printing
>>> >> out
>>> >> forecastfixing and some of the index rate:
>>> >> for(int i=0;i<AccuralStart.size();i++){
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>>> >> settlementDate){
>>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>> >> junk << AccuralStart[i] << " +++ " <<
>>> >> FRN13Wks->fixing(AccuralStart[i])
>>> >> << "
>>> >> +++ " << IndexRate[i] << endl;
>>> >> }
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>>> >> settlementDate){
>>> >> junk << AccuralStart[i] << " ``` " <<
>>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i]
>>> >> <<
>>> >> endl;
>>> >> }
>>> >> }
>>> >>
>>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>> >>
>>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>>> >> rate
>>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>> >> maturity
>>> >> date. Can you or anyone to help me to understand where 0.00000014
>>> >> comes
>>> >> from?
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> >>> > I am trying to price a floating rate bond that depends on the rate
>>> >>> > of a
>>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>> >>> > imported
>>> >>> > from
>>> >>> > the file. But I used IborIndex class for the rate of the
>>> >>> > instrument.
>>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>>> >>> > this
>>> >>> > topic:
>>> >>> >
>>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>>> >>> > like
>>> >>> > IborIndex for LIBOR, in QuantLib?
>>> >>>
>>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> >>> your Treasury instrument derived from that?  And instead of looking
>>> >>> at
>>> >>> the price of the bond (that is, at the sum of the coupons, which
>>> >>> muddies things), have you tried first looking at forecast IborIndex
>>> >>> fixings to see if they match the rates you expect?
>>> >>>
>>> >>> > 2 if the answer is no, is it possible to build a class like
>>> >>> > TreasuryIndex by
>>> >>> > extending InterestRateIndex? What would be the challenge in
>>> >>> > building
>>> >>> > TreasuryIndex?
>>> >>>
>>> >>> You would have to implement the forecastFixing method so that it
>>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to
>>> >>> forecast
>>> >>> the rate off your treasury curve. (You&apos;d also have to implement
>>> >>> the
>>> >>> maturityDate method, but that&apos;s easy).
>
>>> >>>
>>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>> >>> > tweaking
>>> >>> > the
>>> >>> > calendar alone? What else needs to be done to make it work?
>>> >>>
>>> >>> See above. It depends on how much the conventions differ.
>>> >>>
>>> >>> > 4      Can someone point me to the right direction on how to
>>> >>> > leverage
>>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> >>> > instrument as the index after a peek at the code?
>>> >>>
>>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>> >>> shouldn&apos;t
>
>>> >>> be that difficult. Once you have a rate class, you should be able to
>>> >>> use the existing classes as you did in your code.
>>> >>>
>>> >>> Let me know how it works.
>>> >>>
>>> >>> Later,
>>> >>>    Luigi
>>> >>>
>>> >>>
>>> >>> --
>>> >>> <https://implementingquantlib.blogspot.com/>
>>> >>> <https://twitter.com/lballabio>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > <https://implementingquantlib.blogspot.com/>
>>> > <https://twitter.com/lballabio>
>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com/>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com/>
> <https://twitter.com/lballabio>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

More on approach A

/////    approach A

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

//////

With the approach A, I used to term structures in the program, TB13WksRateTermStructure, which is basically the original index rate, is used in calling FloatingRateBond FRN whose evaluation date is 07/31/12. discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount Margin) that is used in FRN.setPricingEngine(FRNEngine) and its evaluation date is 09/13/12. But setting the evaluation date for discountRateTermStructureImplied doesn't make any difference for the final results, as shown below:

---------------------------Date(13, September, 2012)

boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13, September, 2012)));

--Today is September 13th, 2012

FRN Net present value1000267.9088

   FRN Clean price99.999275416

   FRN Dirty price100.02740216

0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 % Actual/360 simple compounding

0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1

0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 | 0.220000 % Actual/360 simple compounding

0  D  discountRateTermStructureImplied->discount: September 13th, 2012 | 1

--------------------------------Date(31, July, 2012)

boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31, July, 2012)));

Today is September 13th, 2012

FRN Net present value999998.98404

   FRN Clean price99.999275416

   FRN Dirty price100.02740216

0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 % Actual/360 simple compounding

0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1

0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 | 0.215000 % Actual/360 simple compounding

0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1

It seems that it doesn't make difference in the price on which term structure the priceEngine links to. How can that be? May be the priceEngine automatically linked to the term structure defined by <IborIndex> when calling the FloatingRateBond?

Thanks for your help.

On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:

more on approach B

////////           Approach B

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

////////////

the program will not error out with 'egative time (-0.0111111) given' and give some result after the first date in the input index rate file was moved from 09/18 to 09/13. But it is not right, because the discount factor should be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to the fact that the interested start to accrue on 09/13 not 09/18, thought the discount factor should be 1 on 09/18. This is because the instrument used for index rate is issued every Thursday.  So the dilemma is that the date when the interest accrual starts and the date where discount factor equals to 1 are different! That only invalidate the approach B. But I would think someone must have dealt this kind of dilemma long ago. 

On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:

Luigi,

I was not able to make the program much smaller than it used to be. I simply removed the printing sections. I divided the code to two programs, one for the approach A and the other for the approach B. They are almost identical except that the approach B uses ASDateOriginal.dat and IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and use ImpliedTermStructure to set evaluation date for term structure used by floating rate note price engine to 09/13/12. Somehow, resetting the evaluation date doesn't make any difference in the result

In the approach A, the program use 07/01/12 as the evaluation date for TB13WksRateTermStructure that is the input when calling FloatingRateBond FRN(...). the evaluation date for discountRateTermStructureImplied that is used in FRN.setPricingEngine. Actually, I am not sure that index structure in FRN and the term structure used in its price engine can have two different evaluation date. this approach erred out with 'negative time (-0.0111111) given'

the program for A and B attached. also the data file for A and B are attached. B uses *original* files

Thank you!

On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]> wrote:

Can you post a minimal program to replicate this?

Luigi

On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
> Luigi,
>
> Thank you very much for your time and help!
>
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
> I use two yield term structure. TB13WksRateTermStructure, basically is the
> zero rate of original file whose evaluation date is 7/31 because the
> original file starts with 7/31/12. Then I use ImpliedTermStructure to set
> the evaluation date to 09/18 to create another yield term structure,
> discountRateTermStructureImplied. TB13WksRateTermStructure is the input for
> FloatingRateBond FRN and discountRateTermStructureImplied is linked to
> FRNEngine. But the result, dirty/clean price turns out to be the same as
> before the evaluation date of the yield term structured used for the engine
> was set to 09/18/12. Any way, it doesn't make difference on the price.
>
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
> I remove the data before 09/18/12 from both the index file and the accrual
> date file. But the program errored out with
> AccuralStartSize = 680
> IndexRateFileSize = 680
> negative time (-0.0111111) given
>
> I tried to locate where exactly the program failed. The closest I could get
> is
>> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line 155 C++
>   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 + 0xe
> bytes C++
>   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258 + 0xb
> bytes C++
>   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
>   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
> it failed while calculate NPV().
>
> So my questions is why setting the evaluation date to 09/18 for the discount
> term structure used for price engine didn't make any difference on price and
> what could be possible reason that the approach B failed. Your help will be
> greatly appreciated.
>
> Best Regards,
> Steve
>
>
> From: Luigi Ballabio <[hidden email]>
> To: Steve <[hidden email]>
> Cc: QuantLib users <[hidden email]>
> Sent: Friday, October 4, 2013 9:23 AM
> Subject: Re: [Quantlib-users] pricing a floating rate bond
>
> Steve,
>     just setting the evaluation date doesn&apos;t work because if you
>
> specify a reference date for the curve, it overrides the evaluation
> date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using the
>
> first passed date as reference date.  (For more info, see
> <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>
> Now, there are solutions for this, but there are different possible
> behaviors when moving the reference date (as you tried to do when
> changing the evaluation date) and you&apos;ll have to choose the solution
>
> based on the one you want.
>
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you&apos;ll have to rebuild your
>
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
>
> If you want to move the whole thing two months ahead (that is, to have
> discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
> at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll also
>
> have to rebuild your data set and build a new curve.  For other types
> of curves (not for InterpolatedZeroCurve, though) it&apos;s possible to
>
> have this done automatically when the evaluation date changes; see the
> link I&apos;ve posted above.
>
>
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
>
> Later,
>     Luigi
>
>
> On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> Luiqi,
>>
>> Thank you for your help. I found one of the root problems. I used
>> InterpolatedZeroCurve to return the corresponding Interpolation instance,
>> given a set of data point dated between 07/31/12 and 07/31/14. However, I
>> intended to set 09/19/12 as the settlement date and I did so in the
>> program
>> using Settings::instance().evaluationDate(). But I just found out that the
>> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>> discount factors and in turn in clean and dirty prices. Please see the
>> attachment for the program. I wonder why assigning Settings doesn&apos;t
>> work. Do
>
>> I need to define YieldTermStructure instance with a specified reference
>> date?
>>
>> ===========setting evaluation date
>> Natural settlementDays = 1;
>> Integer fixingDays = 4;
>>
>> DayCounter DMCalcCounter = Actual360();
>> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>
>>    Date settlementDate(19, September, 2012);
>>        // must be a business day
>>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>
>>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> -fixingDays, Days);
>> cout << "Today is " << todaysDate << endl;
>>        // nothing to do with Date::todaysDate
>>        Settings::instance().evaluationDate() = todaysDate;
>>
>> =============discount factor
>> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple compounding
>> 0 discount factor July 31st, 2012 ^^^ 1
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio <[hidden email]>
>> wrote:
>>>
>>> Steve,
>>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>> so the 0.00105 rate you&apos;re passing gets interpreted as such.  When
>>> you
>
>>> later ask for the index fixing, the code calculates the corresponding
>>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>> (it&apos;s
>
>>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13 weeks
>>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>> to the correspondingly continuously compounded rate (same formula as
>>> above, but inverted) and pass that one to the curve.
>>>
>>> However, this will work only as long as the rate is constant. If the
>>> forecast index fixings vary in time, the zero rates will no longer be
>>> the same as the index rates, even converting the compounding (the zero
>>> rates are the average of the forward rates).  You&apos;d be much better
>>> off
>
>>> if your system could give you, for instance, sampled discount factors
>>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>> rates
>
>>> or the discount factors yourself.
>>>
>>> Hope this helps,
>>>    Luigi
>>>
>>>
>>>
>>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>> <[hidden email]> wrote:
>>> > Steve,
>>> >    may you send the data files you&apos;re using so that we can
>>> > actually
>
>>> > run your code?
>>> >
>>> > Luigi
>>> >
>>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>> >> Luigi,
>>> >>
>>> >> I tried to use IborIndex to price the floating note. The result is
>>> >> about
>>> >> 0.0036% off from the correct answer. There are many factors that
>>> >> contribute
>>> >> to this discrepancy. But I think the main reason is that the
>>> >> forecastfixing
>>> >> is about 0.013% off from the index rate. Below are the code printing
>>> >> out
>>> >> forecastfixing and some of the index rate:
>>> >> for(int i=0;i<AccuralStart.size();i++){
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] <
>>> >> settlementDate){
>>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>> >> junk << AccuralStart[i] << " +++ " <<
>>> >> FRN13Wks->fixing(AccuralStart[i])
>>> >> << "
>>> >> +++ " << IndexRate[i] << endl;
>>> >> }
>>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) && AccuralStart[i] >=
>>> >> settlementDate){
>>> >> junk << AccuralStart[i] << " ``` " <<
>>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " << IndexRate[i]
>>> >> <<
>>> >> endl;
>>> >> }
>>> >> }
>>> >>
>>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>> >>
>>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the index
>>> >> rate
>>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>> >> maturity
>>> >> date. Can you or anyone to help me to understand where 0.00000014
>>> >> comes
>>> >> from?
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>> >>> > I am trying to price a floating rate bond that depends on the rate
>>> >>> > of a
>>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>> >>> > imported
>>> >>> > from
>>> >>> > the file. But I used IborIndex class for the rate of the
>>> >>> > instrument.
>>> >>> > Unsurprisingly, the result is way off. So I have a few questions on
>>> >>> > this
>>> >>> > topic:
>>> >>> >
>>> >>> > 1 is there an equivalent index class for the Treasury instrument,
>>> >>> > like
>>> >>> > IborIndex for LIBOR, in QuantLib?
>>> >>>
>>> >>> Not as such.  You might use IborIndex as a proxy, provided that the
>>> >>> conventions match; for instance, the LIBOR rate is simply compounded,
>>> >>> with an Actual/360 day-count convention in the case of USD LIBOR.  As
>>> >>> far as I know, T-bills are quoted as a discount; how is the rate of
>>> >>> your Treasury instrument derived from that?  And instead of looking
>>> >>> at
>>> >>> the price of the bond (that is, at the sum of the coupons, which
>>> >>> muddies things), have you tried first looking at forecast IborIndex
>>> >>> fixings to see if they match the rates you expect?
>>> >>>
>>> >>> > 2 if the answer is no, is it possible to build a class like
>>> >>> > TreasuryIndex by
>>> >>> > extending InterestRateIndex? What would be the challenge in
>>> >>> > building
>>> >>> > TreasuryIndex?
>>> >>>
>>> >>> You would have to implement the forecastFixing method so that it
>>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able to
>>> >>> forecast
>>> >>> the rate off your treasury curve. (You&apos;d also have to implement
>>> >>> the
>>> >>> maturityDate method, but that&apos;s easy).
>
>>> >>>
>>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>> >>> > tweaking
>>> >>> > the
>>> >>> > calendar alone? What else needs to be done to make it work?
>>> >>>
>>> >>> See above. It depends on how much the conventions differ.
>>> >>>
>>> >>> > 4      Can someone point me to the right direction on how to
>>> >>> > leverage
>>> >>> > QuantLib classes to price a floating rate bond that uses a Treasury
>>> >>> > instrument as the index after a peek at the code?
>>> >>>
>>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>> >>> shouldn&apos;t
>
>>> >>> be that difficult. Once you have a rate class, you should be able to
>>> >>> use the existing classes as you did in your code.
>>> >>>
>>> >>> Let me know how it works.
>>> >>>
>>> >>> Later,
>>> >>>    Luigi
>>> >>>
>>> >>>
>>> >>> --
>>> >>> <https://implementingquantlib.blogspot.com/>
>>> >>> <https://twitter.com/lballabio>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > <https://implementingquantlib.blogspot.com/>
>>> > <https://twitter.com/lballabio>
>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com/>
>>> <https://twitter.com/lballabio>
>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com/>
> <https://twitter.com/lballabio>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Ok, I finally managed to look at your code.

Approach A: the curve moves, and you can see it from the fact that the
NPV changes, but the bond price doesn't change because the engine
always discounts to the settlement date of the bond.  If you move the
evaluation date so that the settlement date is the one you want, you
will see the price move as well.

Approach B: you're probably trying to get rates (or discounts) between
the evaluation date and the start of the zero curve, although finding
out exactly why would require some time with a debugger. I suspect
that the settlement date of the bond is before the start of the curve,
since you're setting settlementDays = 1.  Since you want the discount
to be 1 on the 18th, and with settlementDays = 1, you probably want to
set the evaluation date to the 17th. You don't have to worry about
when the interest starts accruing: that info is contained into the
coupons, and the bond will take it into account when calculating the
accrued amount.

Luigi



On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:

> More on approach A
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
>
> With the approach A, I used to term structures in the program,
> TB13WksRateTermStructure, which is basically the original index rate, is
> used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
> discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
> Margin) that is used in FRN.setPricingEngine(FRNEngine) and its evaluation
> date is 09/13/12. But setting the evaluation date for
> discountRateTermStructureImplied doesn't make any difference for the final
> results, as shown below:
> ---------------------------Date(13, September, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
> September, 2012)));
> --Today is September 13th, 2012
> FRN Net present value1000267.9088
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
> 0.220000 % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: September 13th, 2012 | 1
>
> --------------------------------Date(31, July, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31, July,
> 2012)));
> Today is September 13th, 2012
> FRN Net present value999998.98404
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 | 0.215000
> % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>
>
> It seems that it doesn't make difference in the price on which term
> structure the priceEngine links to. How can that be? May be the priceEngine
> automatically linked to the term structure defined by <IborIndex> when
> calling the FloatingRateBond?
>
>
> Thanks for your help.
>
>
>
> On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>>
>> more on approach B
>> ////////           Approach B
>> If you want to keep your zero-rate data as given, that is, if you want
>> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> as you gave to the interpolated curve, you'll have to rebuild your
>> curve; that is, remove the data before 09/17/12, add a new data point
>> at 09/17/12 as the first point, and rebuild your curve.
>> ////////////
>>
>> the program will not error out with 'egative time (-0.0111111) given' and
>> give some result after the first date in the input index rate file was moved
>> from 09/18 to 09/13. But it is not right, because the discount factor should
>> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date
>> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to
>> the fact that the interested start to accrue on 09/13 not 09/18, thought the
>> discount factor should be 1 on 09/18. This is because the instrument used
>> for index rate is issued every Thursday.  So the dilemma is that the date
>> when the interest accrual starts and the date where discount factor equals
>> to 1 are different! That only invalidate the approach B. But I would think
>> someone must have dealt this kind of dilemma long ago.
>>
>>
>> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>>>
>>> Luigi,
>>>
>>> I was not able to make the program much smaller than it used to be. I
>>> simply removed the printing sections. I divided the code to two programs,
>>> one for the approach A and the other for the approach B. They are almost
>>> identical except that the approach B uses ASDateOriginal.dat and
>>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and
>>> use ImpliedTermStructure to set evaluation date for term structure used by
>>> floating rate note price engine to 09/13/12. Somehow, resetting the
>>> evaluation date doesn't make any difference in the result
>>>
>>> In the approach A, the program use 07/01/12 as the evaluation date for
>>> TB13WksRateTermStructure that is the input when calling FloatingRateBond
>>> FRN(...). the evaluation date for discountRateTermStructureImplied that is
>>> used in FRN.setPricingEngine. Actually, I am not sure that index structure
>>> in FRN and the term structure used in its price engine can have two
>>> different evaluation date. this approach erred out with 'negative time
>>> (-0.0111111) given'
>>>
>>> the program for A and B attached. also the data file for A and B are
>>> attached. B uses *original* files
>>>
>>> Thank you!
>>>
>>>
>>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]>
>>> wrote:
>>>>
>>>> Can you post a minimal program to replicate this?
>>>>
>>>> Luigi
>>>>
>>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
>>>> > Luigi,
>>>> >
>>>> > Thank you very much for your time and help!
>>>> >
>>>> > /////    approach A
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> > //////
>>>> > I use two yield term structure. TB13WksRateTermStructure, basically is
>>>> > the
>>>> > zero rate of original file whose evaluation date is 7/31 because the
>>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure to
>>>> > set
>>>> > the evaluation date to 09/18 to create another yield term structure,
>>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>>>> > input for
>>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked to
>>>> > FRNEngine. But the result, dirty/clean price turns out to be the same
>>>> > as
>>>> > before the evaluation date of the yield term structured used for the
>>>> > engine
>>>> > was set to 09/18/12. Any way, it doesn't make difference on the price.
>>>> >
>>>> > ////////           Approach B
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you'll have to rebuild your
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> > ////////////
>>>> > I remove the data before 09/18/12 from both the index file and the
>>>> > accrual
>>>> > date file. But the program errored out with
>>>> > AccuralStartSize = 680
>>>> > IndexRateFileSize = 680
>>>> > negative time (-0.0111111) given
>>>> >
>>>> > I tried to locate where exactly the program failed. The closest I
>>>> > could get
>>>> > is
>>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152
>>>> >> C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line
>>>> > 155 C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 +
>>>> > 0xe
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258
>>>> > + 0xb
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes
>>>> > C
>>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>>>> > it failed while calculate NPV().
>>>> >
>>>> > So my questions is why setting the evaluation date to 09/18 for the
>>>> > discount
>>>> > term structure used for price engine didn't make any difference on
>>>> > price and
>>>> > what could be possible reason that the approach B failed. Your help
>>>> > will be
>>>> > greatly appreciated.
>>>> >
>>>> > Best Regards,
>>>> > Steve
>>>> >
>>>> >
>>>> > From: Luigi Ballabio <[hidden email]>
>>>> > To: Steve <[hidden email]>
>>>> > Cc: QuantLib users <[hidden email]>
>>>> > Sent: Friday, October 4, 2013 9:23 AM
>>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>>>> >
>>>> > Steve,
>>>> >     just setting the evaluation date doesn&apos;t work because if you
>>>> >
>>>> > specify a reference date for the curve, it overrides the evaluation
>>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using
>>>> > the
>>>> >
>>>> > first passed date as reference date.  (For more info, see
>>>> >
>>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>>>> >
>>>> > Now, there are solutions for this, but there are different possible
>>>> > behaviors when moving the reference date (as you tried to do when
>>>> > changing the evaluation date) and you&apos;ll have to choose the
>>>> > solution
>>>> >
>>>> > based on the one you want.
>>>> >
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you&apos;ll have to rebuild
>>>> > your
>>>> >
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> >
>>>> > If you want to move the whole thing two months ahead (that is, to have
>>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
>>>> > at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll
>>>> > also
>>>> >
>>>> > have to rebuild your data set and build a new curve.  For other types
>>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s possible
>>>> > to
>>>> >
>>>> > have this done automatically when the evaluation date changes; see the
>>>> > link I&apos;ve posted above.
>>>> >
>>>> >
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> >
>>>> > Later,
>>>> >     Luigi
>>>> >
>>>> >
>>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>>>> >> Luiqi,
>>>> >>
>>>> >> Thank you for your help. I found one of the root problems. I used
>>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>>>> >> instance,
>>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>>>> >> However, I
>>>> >> intended to set 09/19/12 as the settlement date and I did so in the
>>>> >> program
>>>> >> using Settings::instance().evaluationDate(). But I just found out
>>>> >> that the
>>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>>>> >> discount factors and in turn in clean and dirty prices. Please see
>>>> >> the
>>>> >> attachment for the program. I wonder why assigning Settings
>>>> >> doesn&apos;t
>>>> >> work. Do
>>>> >
>>>> >> I need to define YieldTermStructure instance with a specified
>>>> >> reference
>>>> >> date?
>>>> >>
>>>> >> ===========setting evaluation date
>>>> >> Natural settlementDays = 1;
>>>> >> Integer fixingDays = 4;
>>>> >>
>>>> >> DayCounter DMCalcCounter = Actual360();
>>>> >> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>>> >>
>>>> >>    Date settlementDate(19, September, 2012);
>>>> >>        // must be a business day
>>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>>> >>
>>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>>>> >> -fixingDays, Days);
>>>> >> cout << "Today is " << todaysDate << endl;
>>>> >>        // nothing to do with Date::todaysDate
>>>> >>        Settings::instance().evaluationDate() = todaysDate;
>>>> >>
>>>> >> =============discount factor
>>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>>>> >> compounding
>>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>>>> >> <[hidden email]>
>>>> >> wrote:
>>>> >>>
>>>> >>> Steve,
>>>> >>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as such.
>>>> >>> When
>>>> >>> you
>>>> >
>>>> >>> later ask for the index fixing, the code calculates the
>>>> >>> corresponding
>>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>>> >>> (it&apos;s
>>>> >
>>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>>>> >>> weeks
>>>> >>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>>> >>> to the correspondingly continuously compounded rate (same formula as
>>>> >>> above, but inverted) and pass that one to the curve.
>>>> >>>
>>>> >>> However, this will work only as long as the rate is constant. If the
>>>> >>> forecast index fixings vary in time, the zero rates will no longer
>>>> >>> be
>>>> >>> the same as the index rates, even converting the compounding (the
>>>> >>> zero
>>>> >>> rates are the average of the forward rates).  You&apos;d be much
>>>> >>> better
>>>> >>> off
>>>> >
>>>> >>> if your system could give you, for instance, sampled discount
>>>> >>> factors
>>>> >>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>>> >>> rates
>>>> >
>>>> >>> or the discount factors yourself.
>>>> >>>
>>>> >>> Hope this helps,
>>>> >>>    Luigi
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>>> >>> <[hidden email]> wrote:
>>>> >>> > Steve,
>>>> >>> >    may you send the data files you&apos;re using so that we can
>>>> >>> > actually
>>>> >
>>>> >>> > run your code?
>>>> >>> >
>>>> >>> > Luigi
>>>> >>> >
>>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>>> >>> >> Luigi,
>>>> >>> >>
>>>> >>> >> I tried to use IborIndex to price the floating note. The result
>>>> >>> >> is
>>>> >>> >> about
>>>> >>> >> 0.0036% off from the correct answer. There are many factors that
>>>> >>> >> contribute
>>>> >>> >> to this discrepancy. But I think the main reason is that the
>>>> >>> >> forecastfixing
>>>> >>> >> is about 0.013% off from the index rate. Below are the code
>>>> >>> >> printing
>>>> >>> >> out
>>>> >>> >> forecastfixing and some of the index rate:
>>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] <
>>>> >>> >> settlementDate){
>>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>>>> >>> >> << "
>>>> >>> >> +++ " << IndexRate[i] << endl;
>>>> >>> >> }
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] >=
>>>> >>> >> settlementDate){
>>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>>>> >>> >> IndexRate[i]
>>>> >>> >> <<
>>>> >>> >> endl;
>>>> >>> >> }
>>>> >>> >> }
>>>> >>> >>
>>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >>
>>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the
>>>> >>> >> index
>>>> >>> >> rate
>>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>>> >>> >> maturity
>>>> >>> >> date. Can you or anyone to help me to understand where 0.00000014
>>>> >>> >> comes
>>>> >>> >> from?
>>>> >>> >>
>>>> >>> >> Thanks
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>>> >>> >> <[hidden email]>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>>> >>> >>> > I am trying to price a floating rate bond that depends on the
>>>> >>> >>> > rate
>>>> >>> >>> > of a
>>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>>> >>> >>> > imported
>>>> >>> >>> > from
>>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>>>> >>> >>> > instrument.
>>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>>>> >>> >>> > questions on
>>>> >>> >>> > this
>>>> >>> >>> > topic:
>>>> >>> >>> >
>>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>>>> >>> >>> > instrument,
>>>> >>> >>> > like
>>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>>>> >>> >>>
>>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided that
>>>> >>> >>> the
>>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>>>> >>> >>> compounded,
>>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>>>> >>> >>> LIBOR.  As
>>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the rate
>>>> >>> >>> of
>>>> >>> >>> your Treasury instrument derived from that?  And instead of
>>>> >>> >>> looking
>>>> >>> >>> at
>>>> >>> >>> the price of the bond (that is, at the sum of the coupons, which
>>>> >>> >>> muddies things), have you tried first looking at forecast
>>>> >>> >>> IborIndex
>>>> >>> >>> fixings to see if they match the rates you expect?
>>>> >>> >>>
>>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>>>> >>> >>> > TreasuryIndex by
>>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>>>> >>> >>> > building
>>>> >>> >>> > TreasuryIndex?
>>>> >>> >>>
>>>> >>> >>> You would have to implement the forecastFixing method so that it
>>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able
>>>> >>> >>> to
>>>> >>> >>> forecast
>>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>>>> >>> >>> implement
>>>> >>> >>> the
>>>> >>> >>> maturityDate method, but that&apos;s easy).
>>>> >
>>>> >>> >>>
>>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>>> >>> >>> > tweaking
>>>> >>> >>> > the
>>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>>>> >>> >>>
>>>> >>> >>> See above. It depends on how much the conventions differ.
>>>> >>> >>>
>>>> >>> >>> > 4      Can someone point me to the right direction on how to
>>>> >>> >>> > leverage
>>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>>>> >>> >>> > Treasury
>>>> >>> >>> > instrument as the index after a peek at the code?
>>>> >>> >>>
>>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>>> >>> >>> shouldn&apos;t
>>>> >
>>>> >>> >>> be that difficult. Once you have a rate class, you should be
>>>> >>> >>> able to
>>>> >>> >>> use the existing classes as you did in your code.
>>>> >>> >>>
>>>> >>> >>> Let me know how it works.
>>>> >>> >>>
>>>> >>> >>> Later,
>>>> >>> >>>    Luigi
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> --
>>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> >>> <https://twitter.com/lballabio>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > <https://implementingquantlib.blogspot.com/>
>>>> >>> > <https://twitter.com/lballabio>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> <https://twitter.com/lballabio>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > <https://implementingquantlib.blogspot.com/>
>>>> > <https://twitter.com/lballabio>
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > October Webinars: Code for Performance
>>>> > Free Intel webinars can help you accelerate application performance.
>>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> > most
>>>> > from
>>>> > the latest Intel processors and coprocessors. See abstracts and
>>>> > register >
>>>> >
>>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>>> >
>>>> > _______________________________________________
>>>> > QuantLib-users mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> <https://implementingquantlib.blogspot.com>
>>>> <https://twitter.com/lballabio>
>>>
>>>
>>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luigi,

Many thanks for your time. I did some work after receiving your help.

/////    approach A

Finally, if you want to change the evaluation date but keep the
forward rates fixed (that is, to have discount=1 at 09/17/12 and to
have the forward rate between, say, 03/17/13 and 06/17/13 to be the
same as in the original curve) you can use the ImpliedTermStructure
class. It takes the original curve and a new reference date, and
builds a curve with the property above.

//////

Now I understand that the engine automatically set the discount factor =1 for the settlement date-fixingDays. The fixingDays moves the settlementDays and therefore changes the price. The evaluation date only affects the NPV. So in theory, if the evaluation date = settlementDate-fixingDays, NPV should equal to the dirty price. But it is not the case from my program, though they are close:

Date settlementDate(19, September, 2012);

Integer fixingDays = 4;     //there are 4 business days between 09/13/12 and 09/19/12

Date todaysDate = DMCalccalendar.advance(settlementDate, -fixingDays, Days);

boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13, September, 2012)));

Today is September 13th, 2012

FRN Net present value: 1000267.9088

 FRN Clean price: 99.999275416

 FRN Dirty price: 100.02740216

So NPV and the dirty price are off by about 7 dollars with $1 million in face amount. I am not sure there the difference between the NPV and the dirty price comes from.

Another thing I noticed is that the first cash flow is not affected by the rate before the settlement date. In the index rate file attached you can see that the rate after the settlement date is pretty much the same and in turn the coupon payments after the settlement date stay pretty much the same. However, the first coupon payment should be different from the other coupon payments because the rates before the settlement are significantly different from the rates after the settlement date. Below are the cash flow from the program (settlementDay=09/19/12):

October 31st, 2012: 575.0356132

January 31st, 2013: 575.0356132

April 30th, 2013: 556.2844519

July 31st, 2013: 575.0356132

October 31st, 2013: 575.0356132

January 31st, 2014: 575.0360046

April 30th, 2014: 556.2844519

July 31st, 2014: 575.0356132

July 31st, 2014: 1000000

If the engine had used the rate before the settlement date as it should, the cash flow on October 31st should be significantly less than 575.0356132. It seems that the engine didn't use the rate before the settlement date for calculating the first coupon payment. I cannot figure out what went wrong with my code.

I will have more on approach B later.

Thank you!

On Tue, Nov 19, 2013 at 5:42 PM, Luigi Ballabio <[hidden email]> wrote:

Ok, I finally managed to look at your code.

Approach A: the curve moves, and you can see it from the fact that the
NPV changes, but the bond price doesn't change because the engine
always discounts to the settlement date of the bond.  If you move the
evaluation date so that the settlement date is the one you want, you
will see the price move as well.

Approach B: you're probably trying to get rates (or discounts) between
the evaluation date and the start of the zero curve, although finding
out exactly why would require some time with a debugger. I suspect
that the settlement date of the bond is before the start of the curve,
since you're setting settlementDays = 1.  Since you want the discount
to be 1 on the 18th, and with settlementDays = 1, you probably want to
set the evaluation date to the 17th. You don't have to worry about
when the interest starts accruing: that info is contained into the
coupons, and the bond will take it into account when calculating the
accrued amount.

Luigi

On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:
> More on approach A
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
>
> With the approach A, I used to term structures in the program,
> TB13WksRateTermStructure, which is basically the original index rate, is
> used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
> discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
> Margin) that is used in FRN.setPricingEngine(FRNEngine) and its evaluation
> date is 09/13/12. But setting the evaluation date for
> discountRateTermStructureImplied doesn't make any difference for the final
> results, as shown below:
> ---------------------------Date(13, September, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
> September, 2012)));
> --Today is September 13th, 2012
> FRN Net present value1000267.9088
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
> 0.220000 % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: September 13th, 2012 | 1
>
> --------------------------------Date(31, July, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31, July,
> 2012)));
> Today is September 13th, 2012
> FRN Net present value999998.98404
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 | 0.215000
> % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>
>
> It seems that it doesn't make difference in the price on which term
> structure the priceEngine links to. How can that be? May be the priceEngine
> automatically linked to the term structure defined by <IborIndex> when
> calling the FloatingRateBond?
>
>
> Thanks for your help.
>
>
>
> On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>>
>> more on approach B
>> ////////           Approach B
>> If you want to keep your zero-rate data as given, that is, if you want
>> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> as you gave to the interpolated curve, you'll have to rebuild your
>> curve; that is, remove the data before 09/17/12, add a new data point
>> at 09/17/12 as the first point, and rebuild your curve.
>> ////////////
>>
>> the program will not error out with 'egative time (-0.0111111) given' and
>> give some result after the first date in the input index rate file was moved
>> from 09/18 to 09/13. But it is not right, because the discount factor should
>> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date
>> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to
>> the fact that the interested start to accrue on 09/13 not 09/18, thought the
>> discount factor should be 1 on 09/18. This is because the instrument used
>> for index rate is issued every Thursday.  So the dilemma is that the date
>> when the interest accrual starts and the date where discount factor equals
>> to 1 are different! That only invalidate the approach B. But I would think
>> someone must have dealt this kind of dilemma long ago.
>>
>>
>> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>>>
>>> Luigi,
>>>
>>> I was not able to make the program much smaller than it used to be. I
>>> simply removed the printing sections. I divided the code to two programs,
>>> one for the approach A and the other for the approach B. They are almost
>>> identical except that the approach B uses ASDateOriginal.dat and
>>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and
>>> use ImpliedTermStructure to set evaluation date for term structure used by
>>> floating rate note price engine to 09/13/12. Somehow, resetting the
>>> evaluation date doesn't make any difference in the result
>>>
>>> In the approach A, the program use 07/01/12 as the evaluation date for
>>> TB13WksRateTermStructure that is the input when calling FloatingRateBond
>>> FRN(...). the evaluation date for discountRateTermStructureImplied that is
>>> used in FRN.setPricingEngine. Actually, I am not sure that index structure
>>> in FRN and the term structure used in its price engine can have two
>>> different evaluation date. this approach erred out with 'negative time
>>> (-0.0111111) given'
>>>
>>> the program for A and B attached. also the data file for A and B are
>>> attached. B uses *original* files
>>>
>>> Thank you!
>>>
>>>
>>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]>
>>> wrote:
>>>>
>>>> Can you post a minimal program to replicate this?
>>>>
>>>> Luigi
>>>>
>>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
>>>> > Luigi,
>>>> >
>>>> > Thank you very much for your time and help!
>>>> >
>>>> > /////    approach A
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> > //////
>>>> > I use two yield term structure. TB13WksRateTermStructure, basically is
>>>> > the
>>>> > zero rate of original file whose evaluation date is 7/31 because the
>>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure to
>>>> > set
>>>> > the evaluation date to 09/18 to create another yield term structure,
>>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>>>> > input for
>>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked to
>>>> > FRNEngine. But the result, dirty/clean price turns out to be the same
>>>> > as
>>>> > before the evaluation date of the yield term structured used for the
>>>> > engine
>>>> > was set to 09/18/12. Any way, it doesn't make difference on the price.
>>>> >
>>>> > ////////           Approach B
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you'll have to rebuild your
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> > ////////////
>>>> > I remove the data before 09/18/12 from both the index file and the
>>>> > accrual
>>>> > date file. But the program errored out with
>>>> > AccuralStartSize = 680
>>>> > IndexRateFileSize = 680
>>>> > negative time (-0.0111111) given
>>>> >
>>>> > I tried to locate where exactly the program failed. The closest I
>>>> > could get
>>>> > is
>>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152
>>>> >> C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line
>>>> > 155 C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 +
>>>> > 0xe
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258
>>>> > + 0xb
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes
>>>> > C
>>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>>>> > it failed while calculate NPV().
>>>> >
>>>> > So my questions is why setting the evaluation date to 09/18 for the
>>>> > discount
>>>> > term structure used for price engine didn't make any difference on
>>>> > price and
>>>> > what could be possible reason that the approach B failed. Your help
>>>> > will be
>>>> > greatly appreciated.
>>>> >
>>>> > Best Regards,
>>>> > Steve
>>>> >
>>>> >
>>>> > From: Luigi Ballabio <[hidden email]>
>>>> > To: Steve <[hidden email]>
>>>> > Cc: QuantLib users <[hidden email]>
>>>> > Sent: Friday, October 4, 2013 9:23 AM
>>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>>>> >
>>>> > Steve,
>>>> >     just setting the evaluation date doesn&apos;t work because if you
>>>> >
>>>> > specify a reference date for the curve, it overrides the evaluation
>>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using
>>>> > the
>>>> >
>>>> > first passed date as reference date.  (For more info, see
>>>> >
>>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>>>> >
>>>> > Now, there are solutions for this, but there are different possible
>>>> > behaviors when moving the reference date (as you tried to do when
>>>> > changing the evaluation date) and you&apos;ll have to choose the
>>>> > solution
>>>> >
>>>> > based on the one you want.
>>>> >
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you&apos;ll have to rebuild
>>>> > your
>>>> >
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> >
>>>> > If you want to move the whole thing two months ahead (that is, to have
>>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
>>>> > at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll
>>>> > also
>>>> >
>>>> > have to rebuild your data set and build a new curve.  For other types
>>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s possible
>>>> > to
>>>> >
>>>> > have this done automatically when the evaluation date changes; see the
>>>> > link I&apos;ve posted above.
>>>> >
>>>> >
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> >
>>>> > Later,
>>>> >     Luigi
>>>> >
>>>> >
>>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>>>> >> Luiqi,
>>>> >>
>>>> >> Thank you for your help. I found one of the root problems. I used
>>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>>>> >> instance,
>>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>>>> >> However, I
>>>> >> intended to set 09/19/12 as the settlement date and I did so in the
>>>> >> program
>>>> >> using Settings::instance().evaluationDate(). But I just found out
>>>> >> that the
>>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>>>> >> discount factors and in turn in clean and dirty prices. Please see
>>>> >> the
>>>> >> attachment for the program. I wonder why assigning Settings
>>>> >> doesn&apos;t
>>>> >> work. Do
>>>> >
>>>> >> I need to define YieldTermStructure instance with a specified
>>>> >> reference
>>>> >> date?
>>>> >>
>>>> >> ===========setting evaluation date
>>>> >> Natural settlementDays = 1;
>>>> >> Integer fixingDays = 4;
>>>> >>
>>>> >> DayCounter DMCalcCounter = Actual360();
>>>> >> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>>> >>
>>>> >>    Date settlementDate(19, September, 2012);
>>>> >>        // must be a business day
>>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>>> >>
>>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>>>> >> -fixingDays, Days);
>>>> >> cout << "Today is " << todaysDate << endl;
>>>> >>        // nothing to do with Date::todaysDate
>>>> >>        Settings::instance().evaluationDate() = todaysDate;
>>>> >>
>>>> >> =============discount factor
>>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>>>> >> compounding
>>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>>>> >> <[hidden email]>
>>>> >> wrote:
>>>> >>>
>>>> >>> Steve,
>>>> >>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as such.
>>>> >>> When
>>>> >>> you
>>>> >
>>>> >>> later ask for the index fixing, the code calculates the
>>>> >>> corresponding
>>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>>> >>> (it&apos;s
>>>> >
>>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>>>> >>> weeks
>>>> >>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>>> >>> to the correspondingly continuously compounded rate (same formula as
>>>> >>> above, but inverted) and pass that one to the curve.
>>>> >>>
>>>> >>> However, this will work only as long as the rate is constant. If the
>>>> >>> forecast index fixings vary in time, the zero rates will no longer
>>>> >>> be
>>>> >>> the same as the index rates, even converting the compounding (the
>>>> >>> zero
>>>> >>> rates are the average of the forward rates).  You&apos;d be much
>>>> >>> better
>>>> >>> off
>>>> >
>>>> >>> if your system could give you, for instance, sampled discount
>>>> >>> factors
>>>> >>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>>> >>> rates
>>>> >
>>>> >>> or the discount factors yourself.
>>>> >>>
>>>> >>> Hope this helps,
>>>> >>>    Luigi
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>>> >>> <[hidden email]> wrote:
>>>> >>> > Steve,
>>>> >>> >    may you send the data files you&apos;re using so that we can
>>>> >>> > actually
>>>> >
>>>> >>> > run your code?
>>>> >>> >
>>>> >>> > Luigi
>>>> >>> >
>>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>>> >>> >> Luigi,
>>>> >>> >>
>>>> >>> >> I tried to use IborIndex to price the floating note. The result
>>>> >>> >> is
>>>> >>> >> about
>>>> >>> >> 0.0036% off from the correct answer. There are many factors that
>>>> >>> >> contribute
>>>> >>> >> to this discrepancy. But I think the main reason is that the
>>>> >>> >> forecastfixing
>>>> >>> >> is about 0.013% off from the index rate. Below are the code
>>>> >>> >> printing
>>>> >>> >> out
>>>> >>> >> forecastfixing and some of the index rate:
>>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] <
>>>> >>> >> settlementDate){
>>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>>>> >>> >> << "
>>>> >>> >> +++ " << IndexRate[i] << endl;
>>>> >>> >> }
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] >=
>>>> >>> >> settlementDate){
>>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>>>> >>> >> IndexRate[i]
>>>> >>> >> <<
>>>> >>> >> endl;
>>>> >>> >> }
>>>> >>> >> }
>>>> >>> >>
>>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >>
>>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the
>>>> >>> >> index
>>>> >>> >> rate
>>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>>> >>> >> maturity
>>>> >>> >> date. Can you or anyone to help me to understand where 0.00000014
>>>> >>> >> comes
>>>> >>> >> from?
>>>> >>> >>
>>>> >>> >> Thanks
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>>> >>> >> <[hidden email]>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>>> >>> >>> > I am trying to price a floating rate bond that depends on the
>>>> >>> >>> > rate
>>>> >>> >>> > of a
>>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>>> >>> >>> > imported
>>>> >>> >>> > from
>>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>>>> >>> >>> > instrument.
>>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>>>> >>> >>> > questions on
>>>> >>> >>> > this
>>>> >>> >>> > topic:
>>>> >>> >>> >
>>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>>>> >>> >>> > instrument,
>>>> >>> >>> > like
>>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>>>> >>> >>>
>>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided that
>>>> >>> >>> the
>>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>>>> >>> >>> compounded,
>>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>>>> >>> >>> LIBOR.  As
>>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the rate
>>>> >>> >>> of
>>>> >>> >>> your Treasury instrument derived from that?  And instead of
>>>> >>> >>> looking
>>>> >>> >>> at
>>>> >>> >>> the price of the bond (that is, at the sum of the coupons, which
>>>> >>> >>> muddies things), have you tried first looking at forecast
>>>> >>> >>> IborIndex
>>>> >>> >>> fixings to see if they match the rates you expect?
>>>> >>> >>>
>>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>>>> >>> >>> > TreasuryIndex by
>>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>>>> >>> >>> > building
>>>> >>> >>> > TreasuryIndex?
>>>> >>> >>>
>>>> >>> >>> You would have to implement the forecastFixing method so that it
>>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able
>>>> >>> >>> to
>>>> >>> >>> forecast
>>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>>>> >>> >>> implement
>>>> >>> >>> the
>>>> >>> >>> maturityDate method, but that&apos;s easy).
>>>> >
>>>> >>> >>>
>>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>>> >>> >>> > tweaking
>>>> >>> >>> > the
>>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>>>> >>> >>>
>>>> >>> >>> See above. It depends on how much the conventions differ.
>>>> >>> >>>
>>>> >>> >>> > 4      Can someone point me to the right direction on how to
>>>> >>> >>> > leverage
>>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>>>> >>> >>> > Treasury
>>>> >>> >>> > instrument as the index after a peek at the code?
>>>> >>> >>>
>>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>>> >>> >>> shouldn&apos;t
>>>> >
>>>> >>> >>> be that difficult. Once you have a rate class, you should be
>>>> >>> >>> able to
>>>> >>> >>> use the existing classes as you did in your code.
>>>> >>> >>>
>>>> >>> >>> Let me know how it works.
>>>> >>> >>>
>>>> >>> >>> Later,
>>>> >>> >>>    Luigi
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> --
>>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> >>> <https://twitter.com/lballabio>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > <https://implementingquantlib.blogspot.com/>
>>>> >>> > <https://twitter.com/lballabio>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> <https://twitter.com/lballabio>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > <https://implementingquantlib.blogspot.com/>
>>>> > <https://twitter.com/lballabio>
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > October Webinars: Code for Performance
>>>> > Free Intel webinars can help you accelerate application performance.
>>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> > most
>>>> > from
>>>> > the latest Intel processors and coprocessors. See abstracts and
>>>> > register >
>>>> >
>>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>>> >
>>>> > _______________________________________________
>>>> > QuantLib-users mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> <https://implementingquantlib.blogspot.com>
>>>> <https://twitter.com/lballabio>
>>>
>>>
>>
>



--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

More one approach B

////////           Approach B

If you want to keep your zero-rate data as given, that is, if you want
discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
as you gave to the interpolated curve, you'll have to rebuild your
curve; that is, remove the data before 09/17/12, add a new data point
at 09/17/12 as the first point, and rebuild your curve.

////////////

The problem with this approach is that the curve will not be exposed to the rates before 09/17/12 because the data before 09/17/12 is removed. Because the data before 09/17/12 is not available, the QuantLib will derive the first coupon payment based on the rates after 09/17/12. The result is that the first coupon is noticeably less the correct coupon because the rates before 09/17/12 is lower than that after 09/17/12. 

It seems that both approach A and B have the same issue that the rate before evaluation date is not used for computing the first coupon. Maybe I didn't do something right.

Thank you for your help.

On Tue, Nov 19, 2013 at 5:42 PM, Luigi Ballabio <[hidden email]> wrote:

Ok, I finally managed to look at your code.

Approach A: the curve moves, and you can see it from the fact that the
NPV changes, but the bond price doesn't change because the engine
always discounts to the settlement date of the bond.  If you move the
evaluation date so that the settlement date is the one you want, you
will see the price move as well.

Approach B: you're probably trying to get rates (or discounts) between
the evaluation date and the start of the zero curve, although finding
out exactly why would require some time with a debugger. I suspect
that the settlement date of the bond is before the start of the curve,
since you're setting settlementDays = 1.  Since you want the discount
to be 1 on the 18th, and with settlementDays = 1, you probably want to
set the evaluation date to the 17th. You don't have to worry about
when the interest starts accruing: that info is contained into the
coupons, and the bond will take it into account when calculating the
accrued amount.

Luigi

On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:
> More on approach A
> /////    approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
>
> With the approach A, I used to term structures in the program,
> TB13WksRateTermStructure, which is basically the original index rate, is
> used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
> discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
> Margin) that is used in FRN.setPricingEngine(FRNEngine) and its evaluation
> date is 09/13/12. But setting the evaluation date for
> discountRateTermStructureImplied doesn't make any difference for the final
> results, as shown below:
> ---------------------------Date(13, September, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
> September, 2012)));
> --Today is September 13th, 2012
> FRN Net present value1000267.9088
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
> 0.220000 % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: September 13th, 2012 | 1
>
> --------------------------------Date(31, July, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31, July,
> 2012)));
> Today is September 13th, 2012
> FRN Net present value999998.98404
>    FRN Clean price99.999275416
>    FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 | 0.215000
> % Actual/360 simple compounding
> 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>
>
> It seems that it doesn't make difference in the price on which term
> structure the priceEngine links to. How can that be? May be the priceEngine
> automatically linked to the term structure defined by <IborIndex> when
> calling the FloatingRateBond?
>
>
> Thanks for your help.
>
>
>
> On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>>
>> more on approach B
>> ////////           Approach B
>> If you want to keep your zero-rate data as given, that is, if you want
>> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> as you gave to the interpolated curve, you'll have to rebuild your
>> curve; that is, remove the data before 09/17/12, add a new data point
>> at 09/17/12 as the first point, and rebuild your curve.
>> ////////////
>>
>> the program will not error out with 'egative time (-0.0111111) given' and
>> give some result after the first date in the input index rate file was moved
>> from 09/18 to 09/13. But it is not right, because the discount factor should
>> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date
>> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to
>> the fact that the interested start to accrue on 09/13 not 09/18, thought the
>> discount factor should be 1 on 09/18. This is because the instrument used
>> for index rate is issued every Thursday.  So the dilemma is that the date
>> when the interest accrual starts and the date where discount factor equals
>> to 1 are different! That only invalidate the approach B. But I would think
>> someone must have dealt this kind of dilemma long ago.
>>
>>
>> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>>>
>>> Luigi,
>>>
>>> I was not able to make the program much smaller than it used to be. I
>>> simply removed the printing sections. I divided the code to two programs,
>>> one for the approach A and the other for the approach B. They are almost
>>> identical except that the approach B uses ASDateOriginal.dat and
>>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and
>>> use ImpliedTermStructure to set evaluation date for term structure used by
>>> floating rate note price engine to 09/13/12. Somehow, resetting the
>>> evaluation date doesn't make any difference in the result
>>>
>>> In the approach A, the program use 07/01/12 as the evaluation date for
>>> TB13WksRateTermStructure that is the input when calling FloatingRateBond
>>> FRN(...). the evaluation date for discountRateTermStructureImplied that is
>>> used in FRN.setPricingEngine. Actually, I am not sure that index structure
>>> in FRN and the term structure used in its price engine can have two
>>> different evaluation date. this approach erred out with 'negative time
>>> (-0.0111111) given'
>>>
>>> the program for A and B attached. also the data file for A and B are
>>> attached. B uses *original* files
>>>
>>> Thank you!
>>>
>>>
>>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <[hidden email]>
>>> wrote:
>>>>
>>>> Can you post a minimal program to replicate this?
>>>>
>>>> Luigi
>>>>
>>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
>>>> > Luigi,
>>>> >
>>>> > Thank you very much for your time and help!
>>>> >
>>>> > /////    approach A
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> > //////
>>>> > I use two yield term structure. TB13WksRateTermStructure, basically is
>>>> > the
>>>> > zero rate of original file whose evaluation date is 7/31 because the
>>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure to
>>>> > set
>>>> > the evaluation date to 09/18 to create another yield term structure,
>>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>>>> > input for
>>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked to
>>>> > FRNEngine. But the result, dirty/clean price turns out to be the same
>>>> > as
>>>> > before the evaluation date of the yield term structured used for the
>>>> > engine
>>>> > was set to 09/18/12. Any way, it doesn't make difference on the price.
>>>> >
>>>> > ////////           Approach B
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you'll have to rebuild your
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> > ////////////
>>>> > I remove the data before 09/18/12 from both the index file and the
>>>> > accrual
>>>> > date file. But the program errored out with
>>>> > AccuralStartSize = 680
>>>> > IndexRateFileSize = 680
>>>> > negative time (-0.0111111) given
>>>> >
>>>> > I tried to locate where exactly the program failed. The closest I
>>>> > could get
>>>> > is
>>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line 152
>>>> >> C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line
>>>> > 155 C++
>>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 +
>>>> > 0xe
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line 258
>>>> > + 0xb
>>>> > bytes C++
>>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes
>>>> > C
>>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>>>> > it failed while calculate NPV().
>>>> >
>>>> > So my questions is why setting the evaluation date to 09/18 for the
>>>> > discount
>>>> > term structure used for price engine didn't make any difference on
>>>> > price and
>>>> > what could be possible reason that the approach B failed. Your help
>>>> > will be
>>>> > greatly appreciated.
>>>> >
>>>> > Best Regards,
>>>> > Steve
>>>> >
>>>> >
>>>> > From: Luigi Ballabio <[hidden email]>
>>>> > To: Steve <[hidden email]>
>>>> > Cc: QuantLib users <[hidden email]>
>>>> > Sent: Friday, October 4, 2013 9:23 AM
>>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>>>> >
>>>> > Steve,
>>>> >     just setting the evaluation date doesn&apos;t work because if you
>>>> >
>>>> > specify a reference date for the curve, it overrides the evaluation
>>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by using
>>>> > the
>>>> >
>>>> > first passed date as reference date.  (For more info, see
>>>> >
>>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>>>> >
>>>> > Now, there are solutions for this, but there are different possible
>>>> > behaviors when moving the reference date (as you tried to do when
>>>> > changing the evaluation date) and you&apos;ll have to choose the
>>>> > solution
>>>> >
>>>> > based on the one you want.
>>>> >
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you&apos;ll have to rebuild
>>>> > your
>>>> >
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> >
>>>> > If you want to move the whole thing two months ahead (that is, to have
>>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
>>>> > at 09/17/14 equal to the one you had at 07/31/14 before) you&apos;ll
>>>> > also
>>>> >
>>>> > have to rebuild your data set and build a new curve.  For other types
>>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s possible
>>>> > to
>>>> >
>>>> > have this done automatically when the evaluation date changes; see the
>>>> > link I&apos;ve posted above.
>>>> >
>>>> >
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> >
>>>> > Later,
>>>> >     Luigi
>>>> >
>>>> >
>>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>>>> >> Luiqi,
>>>> >>
>>>> >> Thank you for your help. I found one of the root problems. I used
>>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>>>> >> instance,
>>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>>>> >> However, I
>>>> >> intended to set 09/19/12 as the settlement date and I did so in the
>>>> >> program
>>>> >> using Settings::instance().evaluationDate(). But I just found out
>>>> >> that the
>>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>>>> >> discount factors and in turn in clean and dirty prices. Please see
>>>> >> the
>>>> >> attachment for the program. I wonder why assigning Settings
>>>> >> doesn&apos;t
>>>> >> work. Do
>>>> >
>>>> >> I need to define YieldTermStructure instance with a specified
>>>> >> reference
>>>> >> date?
>>>> >>
>>>> >> ===========setting evaluation date
>>>> >> Natural settlementDays = 1;
>>>> >> Integer fixingDays = 4;
>>>> >>
>>>> >> DayCounter DMCalcCounter = Actual360();
>>>> >> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>>> >>
>>>> >>    Date settlementDate(19, September, 2012);
>>>> >>        // must be a business day
>>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>>>> >>
>>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>>>> >> -fixingDays, Days);
>>>> >> cout << "Today is " << todaysDate << endl;
>>>> >>        // nothing to do with Date::todaysDate
>>>> >>        Settings::instance().evaluationDate() = todaysDate;
>>>> >>
>>>> >> =============discount factor
>>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>>>> >> compounding
>>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>>>> >> <[hidden email]>
>>>> >> wrote:
>>>> >>>
>>>> >>> Steve,
>>>> >>>    InterpolatedZeroCurve expects continuously compounded zero rates,
>>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as such.
>>>> >>> When
>>>> >>> you
>>>> >
>>>> >>> later ask for the index fixing, the code calculates the
>>>> >>> corresponding
>>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re seeing
>>>> >>> (it&apos;s
>>>> >
>>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>>>> >>> weeks
>>>> >>> in your case and r1 = 0.00105).  You can try converting your 0.00105
>>>> >>> to the correspondingly continuously compounded rate (same formula as
>>>> >>> above, but inverted) and pass that one to the curve.
>>>> >>>
>>>> >>> However, this will work only as long as the rate is constant. If the
>>>> >>> forecast index fixings vary in time, the zero rates will no longer
>>>> >>> be
>>>> >>> the same as the index rates, even converting the compounding (the
>>>> >>> zero
>>>> >>> rates are the average of the forward rates).  You&apos;d be much
>>>> >>> better
>>>> >>> off
>>>> >
>>>> >>> if your system could give you, for instance, sampled discount
>>>> >>> factors
>>>> >>> at the same dates. Otherwise you&apos;ll have to figure out the zero
>>>> >>> rates
>>>> >
>>>> >>> or the discount factors yourself.
>>>> >>>
>>>> >>> Hope this helps,
>>>> >>>    Luigi
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>>> >>> <[hidden email]> wrote:
>>>> >>> > Steve,
>>>> >>> >    may you send the data files you&apos;re using so that we can
>>>> >>> > actually
>>>> >
>>>> >>> > run your code?
>>>> >>> >
>>>> >>> > Luigi
>>>> >>> >
>>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]> wrote:
>>>> >>> >> Luigi,
>>>> >>> >>
>>>> >>> >> I tried to use IborIndex to price the floating note. The result
>>>> >>> >> is
>>>> >>> >> about
>>>> >>> >> 0.0036% off from the correct answer. There are many factors that
>>>> >>> >> contribute
>>>> >>> >> to this discrepancy. But I think the main reason is that the
>>>> >>> >> forecastfixing
>>>> >>> >> is about 0.013% off from the index rate. Below are the code
>>>> >>> >> printing
>>>> >>> >> out
>>>> >>> >> forecastfixing and some of the index rate:
>>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] <
>>>> >>> >> settlementDate){
>>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>>>> >>> >> << "
>>>> >>> >> +++ " << IndexRate[i] << endl;
>>>> >>> >> }
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] >=
>>>> >>> >> settlementDate){
>>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>>>> >>> >> IndexRate[i]
>>>> >>> >> <<
>>>> >>> >> endl;
>>>> >>> >> }
>>>> >>> >> }
>>>> >>> >>
>>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >>
>>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the
>>>> >>> >> index
>>>> >>> >> rate
>>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>>> >>> >> maturity
>>>> >>> >> date. Can you or anyone to help me to understand where 0.00000014
>>>> >>> >> comes
>>>> >>> >> from?
>>>> >>> >>
>>>> >>> >> Thanks
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>>> >>> >> <[hidden email]>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]> wrote:
>>>> >>> >>> > I am trying to price a floating rate bond that depends on the
>>>> >>> >>> > rate
>>>> >>> >>> > of a
>>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>>> >>> >>> > imported
>>>> >>> >>> > from
>>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>>>> >>> >>> > instrument.
>>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>>>> >>> >>> > questions on
>>>> >>> >>> > this
>>>> >>> >>> > topic:
>>>> >>> >>> >
>>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>>>> >>> >>> > instrument,
>>>> >>> >>> > like
>>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>>>> >>> >>>
>>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided that
>>>> >>> >>> the
>>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>>>> >>> >>> compounded,
>>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>>>> >>> >>> LIBOR.  As
>>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the rate
>>>> >>> >>> of
>>>> >>> >>> your Treasury instrument derived from that?  And instead of
>>>> >>> >>> looking
>>>> >>> >>> at
>>>> >>> >>> the price of the bond (that is, at the sum of the coupons, which
>>>> >>> >>> muddies things), have you tried first looking at forecast
>>>> >>> >>> IborIndex
>>>> >>> >>> fixings to see if they match the rates you expect?
>>>> >>> >>>
>>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>>>> >>> >>> > TreasuryIndex by
>>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>>>> >>> >>> > building
>>>> >>> >>> > TreasuryIndex?
>>>> >>> >>>
>>>> >>> >>> You would have to implement the forecastFixing method so that it
>>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be able
>>>> >>> >>> to
>>>> >>> >>> forecast
>>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>>>> >>> >>> implement
>>>> >>> >>> the
>>>> >>> >>> maturityDate method, but that&apos;s easy).
>>>> >
>>>> >>> >>>
>>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>>> >>> >>> > tweaking
>>>> >>> >>> > the
>>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>>>> >>> >>>
>>>> >>> >>> See above. It depends on how much the conventions differ.
>>>> >>> >>>
>>>> >>> >>> > 4      Can someone point me to the right direction on how to
>>>> >>> >>> > leverage
>>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>>>> >>> >>> > Treasury
>>>> >>> >>> > instrument as the index after a peek at the code?
>>>> >>> >>>
>>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>>> >>> >>> shouldn&apos;t
>>>> >
>>>> >>> >>> be that difficult. Once you have a rate class, you should be
>>>> >>> >>> able to
>>>> >>> >>> use the existing classes as you did in your code.
>>>> >>> >>>
>>>> >>> >>> Let me know how it works.
>>>> >>> >>>
>>>> >>> >>> Later,
>>>> >>> >>>    Luigi
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> --
>>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> >>> <https://twitter.com/lballabio>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > <https://implementingquantlib.blogspot.com/>
>>>> >>> > <https://twitter.com/lballabio>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> <https://implementingquantlib.blogspot.com/>
>>>> >>> <https://twitter.com/lballabio>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > <https://implementingquantlib.blogspot.com/>
>>>> > <https://twitter.com/lballabio>
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > October Webinars: Code for Performance
>>>> > Free Intel webinars can help you accelerate application performance.
>>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> > most
>>>> > from
>>>> > the latest Intel processors and coprocessors. See abstracts and
>>>> > register >
>>>> >
>>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>>> >
>>>> > _______________________________________________
>>>> > QuantLib-users mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> <https://implementingquantlib.blogspot.com>
>>>> <https://twitter.com/lballabio>
>>>
>>>
>>
>



--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

When is the first coupon fixed? If it fixes before the evaluation
date, it won't use the curve at all. It will use the fixings stored in
the IndexManager instead.

Luigi

On Thu, Nov 28, 2013 at 3:38 AM, Steve <[hidden email]> wrote:

> More one approach B
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
>
> The problem with this approach is that the curve will not be exposed to the
> rates before 09/17/12 because the data before 09/17/12 is removed. Because
> the data before 09/17/12 is not available, the QuantLib will derive the
> first coupon payment based on the rates after 09/17/12. The result is that
> the first coupon is noticeably less the correct coupon because the rates
> before 09/17/12 is lower than that after 09/17/12.
>
> It seems that both approach A and B have the same issue that the rate before
> evaluation date is not used for computing the first coupon. Maybe I didn't
> do something right.
>
> Thank you for your help.
>
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 5:42 PM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> Ok, I finally managed to look at your code.
>>
>> Approach A: the curve moves, and you can see it from the fact that the
>> NPV changes, but the bond price doesn't change because the engine
>> always discounts to the settlement date of the bond.  If you move the
>> evaluation date so that the settlement date is the one you want, you
>> will see the price move as well.
>>
>> Approach B: you're probably trying to get rates (or discounts) between
>> the evaluation date and the start of the zero curve, although finding
>> out exactly why would require some time with a debugger. I suspect
>> that the settlement date of the bond is before the start of the curve,
>> since you're setting settlementDays = 1.  Since you want the discount
>> to be 1 on the 18th, and with settlementDays = 1, you probably want to
>> set the evaluation date to the 17th. You don't have to worry about
>> when the interest starts accruing: that info is contained into the
>> coupons, and the bond will take it into account when calculating the
>> accrued amount.
>>
>> Luigi
>>
>>
>>
>> On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:
>> > More on approach A
>> > /////    approach A
>> > Finally, if you want to change the evaluation date but keep the
>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> > same as in the original curve) you can use the ImpliedTermStructure
>> > class. It takes the original curve and a new reference date, and
>> > builds a curve with the property above.
>> > //////
>> >
>> > With the approach A, I used to term structures in the program,
>> > TB13WksRateTermStructure, which is basically the original index rate, is
>> > used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
>> > discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
>> > Margin) that is used in FRN.setPricingEngine(FRNEngine) and its
>> > evaluation
>> > date is 09/13/12. But setting the evaluation date for
>> > discountRateTermStructureImplied doesn't make any difference for the
>> > final
>> > results, as shown below:
>> > ---------------------------Date(13, September, 2012)
>> > boost::shared_ptr<YieldTermStructure>
>> > discountRateTermStructureImplied(new
>> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
>> > September, 2012)));
>> > --Today is September 13th, 2012
>> > FRN Net present value1000267.9088
>> >    FRN Clean price99.999275416
>> >    FRN Dirty price100.02740216
>> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> > Actual/360 simple compounding
>> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> > 0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
>> > 0.220000 % Actual/360 simple compounding
>> > 0  D  discountRateTermStructureImplied->discount: September 13th, 2012 |
>> > 1
>> >
>> > --------------------------------Date(31, July, 2012)
>> > boost::shared_ptr<YieldTermStructure>
>> > discountRateTermStructureImplied(new
>> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31,
>> > July,
>> > 2012)));
>> > Today is September 13th, 2012
>> > FRN Net present value999998.98404
>> >    FRN Clean price99.999275416
>> >    FRN Dirty price100.02740216
>> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> > Actual/360 simple compounding
>> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> > 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 |
>> > 0.215000
>> > % Actual/360 simple compounding
>> > 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>> >
>> >
>> > It seems that it doesn't make difference in the price on which term
>> > structure the priceEngine links to. How can that be? May be the
>> > priceEngine
>> > automatically linked to the term structure defined by <IborIndex> when
>> > calling the FloatingRateBond?
>> >
>> >
>> > Thanks for your help.
>> >
>> >
>> >
>> > On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>> >>
>> >> more on approach B
>> >> ////////           Approach B
>> >> If you want to keep your zero-rate data as given, that is, if you want
>> >> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> >> as you gave to the interpolated curve, you'll have to rebuild your
>> >> curve; that is, remove the data before 09/17/12, add a new data point
>> >> at 09/17/12 as the first point, and rebuild your curve.
>> >> ////////////
>> >>
>> >> the program will not error out with 'egative time (-0.0111111) given'
>> >> and
>> >> give some result after the first date in the input index rate file was
>> >> moved
>> >> from 09/18 to 09/13. But it is not right, because the discount factor
>> >> should
>> >> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first
>> >> date
>> >> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due
>> >> to
>> >> the fact that the interested start to accrue on 09/13 not 09/18,
>> >> thought the
>> >> discount factor should be 1 on 09/18. This is because the instrument
>> >> used
>> >> for index rate is issued every Thursday.  So the dilemma is that the
>> >> date
>> >> when the interest accrual starts and the date where discount factor
>> >> equals
>> >> to 1 are different! That only invalidate the approach B. But I would
>> >> think
>> >> someone must have dealt this kind of dilemma long ago.
>> >>
>> >>
>> >> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>> >>>
>> >>> Luigi,
>> >>>
>> >>> I was not able to make the program much smaller than it used to be. I
>> >>> simply removed the printing sections. I divided the code to two
>> >>> programs,
>> >>> one for the approach A and the other for the approach B. They are
>> >>> almost
>> >>> identical except that the approach B uses ASDateOriginal.dat and
>> >>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12
>> >>> and
>> >>> use ImpliedTermStructure to set evaluation date for term structure
>> >>> used by
>> >>> floating rate note price engine to 09/13/12. Somehow, resetting the
>> >>> evaluation date doesn't make any difference in the result
>> >>>
>> >>> In the approach A, the program use 07/01/12 as the evaluation date for
>> >>> TB13WksRateTermStructure that is the input when calling
>> >>> FloatingRateBond
>> >>> FRN(...). the evaluation date for discountRateTermStructureImplied
>> >>> that is
>> >>> used in FRN.setPricingEngine. Actually, I am not sure that index
>> >>> structure
>> >>> in FRN and the term structure used in its price engine can have two
>> >>> different evaluation date. this approach erred out with 'negative time
>> >>> (-0.0111111) given'
>> >>>
>> >>> the program for A and B attached. also the data file for A and B are
>> >>> attached. B uses *original* files
>> >>>
>> >>> Thank you!
>> >>>
>> >>>
>> >>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Can you post a minimal program to replicate this?
>> >>>>
>> >>>> Luigi
>> >>>>
>> >>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
>> >>>> > Luigi,
>> >>>> >
>> >>>> > Thank you very much for your time and help!
>> >>>> >
>> >>>> > /////    approach A
>> >>>> > Finally, if you want to change the evaluation date but keep the
>> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> >>>> > same as in the original curve) you can use the ImpliedTermStructure
>> >>>> > class. It takes the original curve and a new reference date, and
>> >>>> > builds a curve with the property above.
>> >>>> > //////
>> >>>> > I use two yield term structure. TB13WksRateTermStructure, basically
>> >>>> > is
>> >>>> > the
>> >>>> > zero rate of original file whose evaluation date is 7/31 because
>> >>>> > the
>> >>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure
>> >>>> > to
>> >>>> > set
>> >>>> > the evaluation date to 09/18 to create another yield term
>> >>>> > structure,
>> >>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>> >>>> > input for
>> >>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked
>> >>>> > to
>> >>>> > FRNEngine. But the result, dirty/clean price turns out to be the
>> >>>> > same
>> >>>> > as
>> >>>> > before the evaluation date of the yield term structured used for
>> >>>> > the
>> >>>> > engine
>> >>>> > was set to 09/18/12. Any way, it doesn't make difference on the
>> >>>> > price.
>> >>>> >
>> >>>> > ////////           Approach B
>> >>>> > If you want to keep your zero-rate data as given, that is, if you
>> >>>> > want
>> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >>>> > same
>> >>>> > as you gave to the interpolated curve, you'll have to rebuild your
>> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >>>> > point
>> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >>>> > ////////////
>> >>>> > I remove the data before 09/18/12 from both the index file and the
>> >>>> > accrual
>> >>>> > date file. But the program errored out with
>> >>>> > AccuralStartSize = 680
>> >>>> > IndexRateFileSize = 680
>> >>>> > negative time (-0.0111111) given
>> >>>> >
>> >>>> > I tried to locate where exactly the program failed. The closest I
>> >>>> > could get
>> >>>> > is
>> >>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line
>> >>>> >> 152
>> >>>> >> C++
>> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line
>> >>>> > 155 C++
>> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 +
>> >>>> > 0xe
>> >>>> > bytes C++
>> >>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line
>> >>>> > 258
>> >>>> > + 0xb
>> >>>> > bytes C++
>> >>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19
>> >>>> > bytes
>> >>>> > C
>> >>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>> >>>> > it failed while calculate NPV().
>> >>>> >
>> >>>> > So my questions is why setting the evaluation date to 09/18 for the
>> >>>> > discount
>> >>>> > term structure used for price engine didn't make any difference on
>> >>>> > price and
>> >>>> > what could be possible reason that the approach B failed. Your help
>> >>>> > will be
>> >>>> > greatly appreciated.
>> >>>> >
>> >>>> > Best Regards,
>> >>>> > Steve
>> >>>> >
>> >>>> >
>> >>>> > From: Luigi Ballabio <[hidden email]>
>> >>>> > To: Steve <[hidden email]>
>> >>>> > Cc: QuantLib users <[hidden email]>
>> >>>> > Sent: Friday, October 4, 2013 9:23 AM
>> >>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>> >>>> >
>> >>>> > Steve,
>> >>>> >     just setting the evaluation date doesn&apos;t work because if
>> >>>> > you
>> >>>> >
>> >>>> > specify a reference date for the curve, it overrides the evaluation
>> >>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by
>> >>>> > using
>> >>>> > the
>> >>>> >
>> >>>> > first passed date as reference date.  (For more info, see
>> >>>> >
>> >>>> >
>> >>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>> >>>> >
>> >>>> > Now, there are solutions for this, but there are different possible
>> >>>> > behaviors when moving the reference date (as you tried to do when
>> >>>> > changing the evaluation date) and you&apos;ll have to choose the
>> >>>> > solution
>> >>>> >
>> >>>> > based on the one you want.
>> >>>> >
>> >>>> > If you want to keep your zero-rate data as given, that is, if you
>> >>>> > want
>> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >>>> > same
>> >>>> > as you gave to the interpolated curve, you&apos;ll have to rebuild
>> >>>> > your
>> >>>> >
>> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >>>> > point
>> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >>>> >
>> >>>> > If you want to move the whole thing two months ahead (that is, to
>> >>>> > have
>> >>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero
>> >>>> > rate
>> >>>> > at 09/17/14 equal to the one you had at 07/31/14 before)
>> >>>> > you&apos;ll
>> >>>> > also
>> >>>> >
>> >>>> > have to rebuild your data set and build a new curve.  For other
>> >>>> > types
>> >>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s
>> >>>> > possible
>> >>>> > to
>> >>>> >
>> >>>> > have this done automatically when the evaluation date changes; see
>> >>>> > the
>> >>>> > link I&apos;ve posted above.
>> >>>> >
>> >>>> >
>> >>>> > Finally, if you want to change the evaluation date but keep the
>> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> >>>> > same as in the original curve) you can use the ImpliedTermStructure
>> >>>> > class. It takes the original curve and a new reference date, and
>> >>>> > builds a curve with the property above.
>> >>>> >
>> >>>> > Later,
>> >>>> >     Luigi
>> >>>> >
>> >>>> >
>> >>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> >>>> >> Luiqi,
>> >>>> >>
>> >>>> >> Thank you for your help. I found one of the root problems. I used
>> >>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>> >>>> >> instance,
>> >>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>> >>>> >> However, I
>> >>>> >> intended to set 09/19/12 as the settlement date and I did so in
>> >>>> >> the
>> >>>> >> program
>> >>>> >> using Settings::instance().evaluationDate(). But I just found out
>> >>>> >> that the
>> >>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off
>> >>>> >> in
>> >>>> >> discount factors and in turn in clean and dirty prices. Please see
>> >>>> >> the
>> >>>> >> attachment for the program. I wonder why assigning Settings
>> >>>> >> doesn&apos;t
>> >>>> >> work. Do
>> >>>> >
>> >>>> >> I need to define YieldTermStructure instance with a specified
>> >>>> >> reference
>> >>>> >> date?
>> >>>> >>
>> >>>> >> ===========setting evaluation date
>> >>>> >> Natural settlementDays = 1;
>> >>>> >> Integer fixingDays = 4;
>> >>>> >>
>> >>>> >> DayCounter DMCalcCounter = Actual360();
>> >>>> >> Calendar DMCalccalendar =
>> >>>> >> UnitedStates(UnitedStates::GovernmentBond);
>> >>>> >>
>> >>>> >>    Date settlementDate(19, September, 2012);
>> >>>> >>        // must be a business day
>> >>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>> >>>> >>
>> >>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> >>>> >> -fixingDays, Days);
>> >>>> >> cout << "Today is " << todaysDate << endl;
>> >>>> >>        // nothing to do with Date::todaysDate
>> >>>> >>        Settings::instance().evaluationDate() = todaysDate;
>> >>>> >>
>> >>>> >> =============discount factor
>> >>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>> >>>> >> compounding
>> >>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>> >>>> >> <[hidden email]>
>> >>>> >> wrote:
>> >>>> >>>
>> >>>> >>> Steve,
>> >>>> >>>    InterpolatedZeroCurve expects continuously compounded zero
>> >>>> >>> rates,
>> >>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as such.
>> >>>> >>> When
>> >>>> >>> you
>> >>>> >
>> >>>> >>> later ask for the index fixing, the code calculates the
>> >>>> >>> corresponding
>> >>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re
>> >>>> >>> seeing
>> >>>> >>> (it&apos;s
>> >>>> >
>> >>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>> >>>> >>> weeks
>> >>>> >>> in your case and r1 = 0.00105).  You can try converting your
>> >>>> >>> 0.00105
>> >>>> >>> to the correspondingly continuously compounded rate (same formula
>> >>>> >>> as
>> >>>> >>> above, but inverted) and pass that one to the curve.
>> >>>> >>>
>> >>>> >>> However, this will work only as long as the rate is constant. If
>> >>>> >>> the
>> >>>> >>> forecast index fixings vary in time, the zero rates will no
>> >>>> >>> longer
>> >>>> >>> be
>> >>>> >>> the same as the index rates, even converting the compounding (the
>> >>>> >>> zero
>> >>>> >>> rates are the average of the forward rates).  You&apos;d be much
>> >>>> >>> better
>> >>>> >>> off
>> >>>> >
>> >>>> >>> if your system could give you, for instance, sampled discount
>> >>>> >>> factors
>> >>>> >>> at the same dates. Otherwise you&apos;ll have to figure out the
>> >>>> >>> zero
>> >>>> >>> rates
>> >>>> >
>> >>>> >>> or the discount factors yourself.
>> >>>> >>>
>> >>>> >>> Hope this helps,
>> >>>> >>>    Luigi
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> >>>> >>> <[hidden email]> wrote:
>> >>>> >>> > Steve,
>> >>>> >>> >    may you send the data files you&apos;re using so that we can
>> >>>> >>> > actually
>> >>>> >
>> >>>> >>> > run your code?
>> >>>> >>> >
>> >>>> >>> > Luigi
>> >>>> >>> >
>> >>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]>
>> >>>> >>> > wrote:
>> >>>> >>> >> Luigi,
>> >>>> >>> >>
>> >>>> >>> >> I tried to use IborIndex to price the floating note. The
>> >>>> >>> >> result
>> >>>> >>> >> is
>> >>>> >>> >> about
>> >>>> >>> >> 0.0036% off from the correct answer. There are many factors
>> >>>> >>> >> that
>> >>>> >>> >> contribute
>> >>>> >>> >> to this discrepancy. But I think the main reason is that the
>> >>>> >>> >> forecastfixing
>> >>>> >>> >> is about 0.013% off from the index rate. Below are the code
>> >>>> >>> >> printing
>> >>>> >>> >> out
>> >>>> >>> >> forecastfixing and some of the index rate:
>> >>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >>>> >>> >> AccuralStart[i] <
>> >>>> >>> >> settlementDate){
>> >>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>> >>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>> >>>> >>> >> << "
>> >>>> >>> >> +++ " << IndexRate[i] << endl;
>> >>>> >>> >> }
>> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >>>> >>> >> AccuralStart[i] >=
>> >>>> >>> >> settlementDate){
>> >>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>> >>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>> >>>> >>> >> IndexRate[i]
>> >>>> >>> >> <<
>> >>>> >>> >> endl;
>> >>>> >>> >> }
>> >>>> >>> >> }
>> >>>> >>> >>
>> >>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >>
>> >>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about
>> >>>> >>> >> the
>> >>>> >>> >> index
>> >>>> >>> >> rate
>> >>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>> >>>> >>> >> maturity
>> >>>> >>> >> date. Can you or anyone to help me to understand where
>> >>>> >>> >> 0.00000014
>> >>>> >>> >> comes
>> >>>> >>> >> from?
>> >>>> >>> >>
>> >>>> >>> >> Thanks
>> >>>> >>> >>
>> >>>> >>> >>
>> >>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >>>> >>> >> <[hidden email]>
>> >>>> >>> >> wrote:
>> >>>> >>> >>>
>> >>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]>
>> >>>> >>> >>> wrote:
>> >>>> >>> >>> > I am trying to price a floating rate bond that depends on
>> >>>> >>> >>> > the
>> >>>> >>> >>> > rate
>> >>>> >>> >>> > of a
>> >>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date
>> >>>> >>> >>> > are
>> >>>> >>> >>> > imported
>> >>>> >>> >>> > from
>> >>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>> >>>> >>> >>> > instrument.
>> >>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>> >>>> >>> >>> > questions on
>> >>>> >>> >>> > this
>> >>>> >>> >>> > topic:
>> >>>> >>> >>> >
>> >>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>> >>>> >>> >>> > instrument,
>> >>>> >>> >>> > like
>> >>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>> >>>> >>> >>>
>> >>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided
>> >>>> >>> >>> that
>> >>>> >>> >>> the
>> >>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>> >>>> >>> >>> compounded,
>> >>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>> >>>> >>> >>> LIBOR.  As
>> >>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the
>> >>>> >>> >>> rate
>> >>>> >>> >>> of
>> >>>> >>> >>> your Treasury instrument derived from that?  And instead of
>> >>>> >>> >>> looking
>> >>>> >>> >>> at
>> >>>> >>> >>> the price of the bond (that is, at the sum of the coupons,
>> >>>> >>> >>> which
>> >>>> >>> >>> muddies things), have you tried first looking at forecast
>> >>>> >>> >>> IborIndex
>> >>>> >>> >>> fixings to see if they match the rates you expect?
>> >>>> >>> >>>
>> >>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>> >>>> >>> >>> > TreasuryIndex by
>> >>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>> >>>> >>> >>> > building
>> >>>> >>> >>> > TreasuryIndex?
>> >>>> >>> >>>
>> >>>> >>> >>> You would have to implement the forecastFixing method so that
>> >>>> >>> >>> it
>> >>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be
>> >>>> >>> >>> able
>> >>>> >>> >>> to
>> >>>> >>> >>> forecast
>> >>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>> >>>> >>> >>> implement
>> >>>> >>> >>> the
>> >>>> >>> >>> maturityDate method, but that&apos;s easy).
>> >>>> >
>> >>>> >>> >>>
>> >>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument
>> >>>> >>> >>> > by
>> >>>> >>> >>> > tweaking
>> >>>> >>> >>> > the
>> >>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>> >>>> >>> >>>
>> >>>> >>> >>> See above. It depends on how much the conventions differ.
>> >>>> >>> >>>
>> >>>> >>> >>> > 4      Can someone point me to the right direction on how
>> >>>> >>> >>> > to
>> >>>> >>> >>> > leverage
>> >>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>> >>>> >>> >>> > Treasury
>> >>>> >>> >>> > instrument as the index after a peek at the code?
>> >>>> >>> >>>
>> >>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>> >>>> >>> >>> shouldn&apos;t
>> >>>> >
>> >>>> >>> >>> be that difficult. Once you have a rate class, you should be
>> >>>> >>> >>> able to
>> >>>> >>> >>> use the existing classes as you did in your code.
>> >>>> >>> >>>
>> >>>> >>> >>> Let me know how it works.
>> >>>> >>> >>>
>> >>>> >>> >>> Later,
>> >>>> >>> >>>    Luigi
>> >>>> >>> >>>
>> >>>> >>> >>>
>> >>>> >>> >>> --
>> >>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>> >>>> >>> >>> <https://twitter.com/lballabio>
>> >>>> >>> >>
>> >>>> >>> >>
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>> > --
>> >>>> >>> > <https://implementingquantlib.blogspot.com/>
>> >>>> >>> > <https://twitter.com/lballabio>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> --
>> >>>> >>> <https://implementingquantlib.blogspot.com/>
>> >>>> >>> <https://twitter.com/lballabio>
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > <https://implementingquantlib.blogspot.com/>
>> >>>> > <https://twitter.com/lballabio>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > ------------------------------------------------------------------------------
>> >>>> > October Webinars: Code for Performance
>> >>>> > Free Intel webinars can help you accelerate application
>> >>>> > performance.
>> >>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> >>>> > most
>> >>>> > from
>> >>>> > the latest Intel processors and coprocessors. See abstracts and
>> >>>> > register >
>> >>>> >
>> >>>> >
>> >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > QuantLib-users mailing list
>> >>>> > [hidden email]
>> >>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> <https://implementingquantlib.blogspot.com>
>> >>>> <https://twitter.com/lballabio>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Steve]

Luigi,

The evaluation date is 09/18 but the first coupon date is 10/31.

Thanks.

On Thu, Nov 28, 2013 at 5:15 AM, Luigi Ballabio <[hidden email]> wrote:

When is the first coupon fixed? If it fixes before the evaluation
date, it won't use the curve at all. It will use the fixings stored in
the IndexManager instead.

Luigi

On Thu, Nov 28, 2013 at 3:38 AM, Steve <[hidden email]> wrote:
> More one approach B
> ////////           Approach B
> If you want to keep your zero-rate data as given, that is, if you want
> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
> as you gave to the interpolated curve, you'll have to rebuild your
> curve; that is, remove the data before 09/17/12, add a new data point
> at 09/17/12 as the first point, and rebuild your curve.
> ////////////
>
> The problem with this approach is that the curve will not be exposed to the
> rates before 09/17/12 because the data before 09/17/12 is removed. Because
> the data before 09/17/12 is not available, the QuantLib will derive the
> first coupon payment based on the rates after 09/17/12. The result is that
> the first coupon is noticeably less the correct coupon because the rates
> before 09/17/12 is lower than that after 09/17/12.
>
> It seems that both approach A and B have the same issue that the rate before
> evaluation date is not used for computing the first coupon. Maybe I didn't
> do something right.
>
> Thank you for your help.
>
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 5:42 PM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> Ok, I finally managed to look at your code.
>>
>> Approach A: the curve moves, and you can see it from the fact that the
>> NPV changes, but the bond price doesn't change because the engine
>> always discounts to the settlement date of the bond.  If you move the
>> evaluation date so that the settlement date is the one you want, you
>> will see the price move as well.
>>
>> Approach B: you're probably trying to get rates (or discounts) between
>> the evaluation date and the start of the zero curve, although finding
>> out exactly why would require some time with a debugger. I suspect
>> that the settlement date of the bond is before the start of the curve,
>> since you're setting settlementDays = 1.  Since you want the discount
>> to be 1 on the 18th, and with settlementDays = 1, you probably want to
>> set the evaluation date to the 17th. You don't have to worry about
>> when the interest starts accruing: that info is contained into the
>> coupons, and the bond will take it into account when calculating the
>> accrued amount.
>>
>> Luigi
>>
>>
>>
>> On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:
>> > More on approach A
>> > /////    approach A
>> > Finally, if you want to change the evaluation date but keep the
>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> > same as in the original curve) you can use the ImpliedTermStructure
>> > class. It takes the original curve and a new reference date, and
>> > builds a curve with the property above.
>> > //////
>> >
>> > With the approach A, I used to term structures in the program,
>> > TB13WksRateTermStructure, which is basically the original index rate, is
>> > used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
>> > discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
>> > Margin) that is used in FRN.setPricingEngine(FRNEngine) and its
>> > evaluation
>> > date is 09/13/12. But setting the evaluation date for
>> > discountRateTermStructureImplied doesn't make any difference for the
>> > final
>> > results, as shown below:
>> > ---------------------------Date(13, September, 2012)
>> > boost::shared_ptr<YieldTermStructure>
>> > discountRateTermStructureImplied(new
>> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
>> > September, 2012)));
>> > --Today is September 13th, 2012
>> > FRN Net present value1000267.9088
>> >    FRN Clean price99.999275416
>> >    FRN Dirty price100.02740216
>> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> > Actual/360 simple compounding
>> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> > 0  D  discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
>> > 0.220000 % Actual/360 simple compounding
>> > 0  D  discountRateTermStructureImplied->discount: September 13th, 2012 |
>> > 1
>> >
>> > --------------------------------Date(31, July, 2012)
>> > boost::shared_ptr<YieldTermStructure>
>> > discountRateTermStructureImplied(new
>> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31,
>> > July,
>> > 2012)));
>> > Today is September 13th, 2012
>> > FRN Net present value999998.98404
>> >    FRN Clean price99.999275416
>> >    FRN Dirty price100.02740216
>> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> > Actual/360 simple compounding
>> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> > 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 |
>> > 0.215000
>> > % Actual/360 simple compounding
>> > 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>> >
>> >
>> > It seems that it doesn't make difference in the price on which term
>> > structure the priceEngine links to. How can that be? May be the
>> > priceEngine
>> > automatically linked to the term structure defined by <IborIndex> when
>> > calling the FloatingRateBond?
>> >
>> >
>> > Thanks for your help.
>> >
>> >
>> >
>> > On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>> >>
>> >> more on approach B
>> >> ////////           Approach B
>> >> If you want to keep your zero-rate data as given, that is, if you want
>> >> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> >> as you gave to the interpolated curve, you'll have to rebuild your
>> >> curve; that is, remove the data before 09/17/12, add a new data point
>> >> at 09/17/12 as the first point, and rebuild your curve.
>> >> ////////////
>> >>
>> >> the program will not error out with 'egative time (-0.0111111) given'
>> >> and
>> >> give some result after the first date in the input index rate file was
>> >> moved
>> >> from 09/18 to 09/13. But it is not right, because the discount factor
>> >> should
>> >> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first
>> >> date
>> >> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due
>> >> to
>> >> the fact that the interested start to accrue on 09/13 not 09/18,
>> >> thought the
>> >> discount factor should be 1 on 09/18. This is because the instrument
>> >> used
>> >> for index rate is issued every Thursday.  So the dilemma is that the
>> >> date
>> >> when the interest accrual starts and the date where discount factor
>> >> equals
>> >> to 1 are different! That only invalidate the approach B. But I would
>> >> think
>> >> someone must have dealt this kind of dilemma long ago.
>> >>
>> >>
>> >> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>> >>>
>> >>> Luigi,
>> >>>
>> >>> I was not able to make the program much smaller than it used to be. I
>> >>> simply removed the printing sections. I divided the code to two
>> >>> programs,
>> >>> one for the approach A and the other for the approach B. They are
>> >>> almost
>> >>> identical except that the approach B uses ASDateOriginal.dat and
>> >>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12
>> >>> and
>> >>> use ImpliedTermStructure to set evaluation date for term structure
>> >>> used by
>> >>> floating rate note price engine to 09/13/12. Somehow, resetting the
>> >>> evaluation date doesn't make any difference in the result
>> >>>
>> >>> In the approach A, the program use 07/01/12 as the evaluation date for
>> >>> TB13WksRateTermStructure that is the input when calling
>> >>> FloatingRateBond
>> >>> FRN(...). the evaluation date for discountRateTermStructureImplied
>> >>> that is
>> >>> used in FRN.setPricingEngine. Actually, I am not sure that index
>> >>> structure
>> >>> in FRN and the term structure used in its price engine can have two
>> >>> different evaluation date. this approach erred out with 'negative time
>> >>> (-0.0111111) given'
>> >>>
>> >>> the program for A and B attached. also the data file for A and B are
>> >>> attached. B uses *original* files
>> >>>
>> >>> Thank you!
>> >>>
>> >>>
>> >>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Can you post a minimal program to replicate this?
>> >>>>
>> >>>> Luigi
>> >>>>
>> >>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]> wrote:
>> >>>> > Luigi,
>> >>>> >
>> >>>> > Thank you very much for your time and help!
>> >>>> >
>> >>>> > /////    approach A
>> >>>> > Finally, if you want to change the evaluation date but keep the
>> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> >>>> > same as in the original curve) you can use the ImpliedTermStructure
>> >>>> > class. It takes the original curve and a new reference date, and
>> >>>> > builds a curve with the property above.
>> >>>> > //////
>> >>>> > I use two yield term structure. TB13WksRateTermStructure, basically
>> >>>> > is
>> >>>> > the
>> >>>> > zero rate of original file whose evaluation date is 7/31 because
>> >>>> > the
>> >>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure
>> >>>> > to
>> >>>> > set
>> >>>> > the evaluation date to 09/18 to create another yield term
>> >>>> > structure,
>> >>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>> >>>> > input for
>> >>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked
>> >>>> > to
>> >>>> > FRNEngine. But the result, dirty/clean price turns out to be the
>> >>>> > same
>> >>>> > as
>> >>>> > before the evaluation date of the yield term structured used for
>> >>>> > the
>> >>>> > engine
>> >>>> > was set to 09/18/12. Any way, it doesn't make difference on the
>> >>>> > price.
>> >>>> >
>> >>>> > ////////           Approach B
>> >>>> > If you want to keep your zero-rate data as given, that is, if you
>> >>>> > want
>> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >>>> > same
>> >>>> > as you gave to the interpolated curve, you'll have to rebuild your
>> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >>>> > point
>> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >>>> > ////////////
>> >>>> > I remove the data before 09/18/12 from both the index file and the
>> >>>> > accrual
>> >>>> > date file. But the program errored out with
>> >>>> > AccuralStartSize = 680
>> >>>> > IndexRateFileSize = 680
>> >>>> > negative time (-0.0111111) given
>> >>>> >
>> >>>> > I tried to locate where exactly the program failed. The closest I
>> >>>> > could get
>> >>>> > is
>> >>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()  Line
>> >>>> >> 152
>> >>>> >> C++
>> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()  Line
>> >>>> > 155 C++
>> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line 187 +
>> >>>> > 0xe
>> >>>> > bytes C++
>> >>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)  Line
>> >>>> > 258
>> >>>> > + 0xb
>> >>>> > bytes C++
>> >>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19
>> >>>> > bytes
>> >>>> > C
>> >>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>> >>>> > it failed while calculate NPV().
>> >>>> >
>> >>>> > So my questions is why setting the evaluation date to 09/18 for the
>> >>>> > discount
>> >>>> > term structure used for price engine didn't make any difference on
>> >>>> > price and
>> >>>> > what could be possible reason that the approach B failed. Your help
>> >>>> > will be
>> >>>> > greatly appreciated.
>> >>>> >
>> >>>> > Best Regards,
>> >>>> > Steve
>> >>>> >
>> >>>> >
>> >>>> > From: Luigi Ballabio <[hidden email]>
>> >>>> > To: Steve <[hidden email]>
>> >>>> > Cc: QuantLib users <[hidden email]>
>> >>>> > Sent: Friday, October 4, 2013 9:23 AM
>> >>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>> >>>> >
>> >>>> > Steve,
>> >>>> >     just setting the evaluation date doesn&apos;t work because if
>> >>>> > you
>> >>>> >
>> >>>> > specify a reference date for the curve, it overrides the evaluation
>> >>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by
>> >>>> > using
>> >>>> > the
>> >>>> >
>> >>>> > first passed date as reference date.  (For more info, see
>> >>>> >
>> >>>> >
>> >>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>> >>>> >
>> >>>> > Now, there are solutions for this, but there are different possible
>> >>>> > behaviors when moving the reference date (as you tried to do when
>> >>>> > changing the evaluation date) and you&apos;ll have to choose the
>> >>>> > solution
>> >>>> >
>> >>>> > based on the one you want.
>> >>>> >
>> >>>> > If you want to keep your zero-rate data as given, that is, if you
>> >>>> > want
>> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >>>> > same
>> >>>> > as you gave to the interpolated curve, you&apos;ll have to rebuild
>> >>>> > your
>> >>>> >
>> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >>>> > point
>> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >>>> >
>> >>>> > If you want to move the whole thing two months ahead (that is, to
>> >>>> > have
>> >>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero
>> >>>> > rate
>> >>>> > at 09/17/14 equal to the one you had at 07/31/14 before)
>> >>>> > you&apos;ll
>> >>>> > also
>> >>>> >
>> >>>> > have to rebuild your data set and build a new curve.  For other
>> >>>> > types
>> >>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s
>> >>>> > possible
>> >>>> > to
>> >>>> >
>> >>>> > have this done automatically when the evaluation date changes; see
>> >>>> > the
>> >>>> > link I&apos;ve posted above.
>> >>>> >
>> >>>> >
>> >>>> > Finally, if you want to change the evaluation date but keep the
>> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> >>>> > same as in the original curve) you can use the ImpliedTermStructure
>> >>>> > class. It takes the original curve and a new reference date, and
>> >>>> > builds a curve with the property above.
>> >>>> >
>> >>>> > Later,
>> >>>> >     Luigi
>> >>>> >
>> >>>> >
>> >>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> >>>> >> Luiqi,
>> >>>> >>
>> >>>> >> Thank you for your help. I found one of the root problems. I used
>> >>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>> >>>> >> instance,
>> >>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>> >>>> >> However, I
>> >>>> >> intended to set 09/19/12 as the settlement date and I did so in
>> >>>> >> the
>> >>>> >> program
>> >>>> >> using Settings::instance().evaluationDate(). But I just found out
>> >>>> >> that the
>> >>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off
>> >>>> >> in
>> >>>> >> discount factors and in turn in clean and dirty prices. Please see
>> >>>> >> the
>> >>>> >> attachment for the program. I wonder why assigning Settings
>> >>>> >> doesn&apos;t
>> >>>> >> work. Do
>> >>>> >
>> >>>> >> I need to define YieldTermStructure instance with a specified
>> >>>> >> reference
>> >>>> >> date?
>> >>>> >>
>> >>>> >> ===========setting evaluation date
>> >>>> >> Natural settlementDays = 1;
>> >>>> >> Integer fixingDays = 4;
>> >>>> >>
>> >>>> >> DayCounter DMCalcCounter = Actual360();
>> >>>> >> Calendar DMCalccalendar =
>> >>>> >> UnitedStates(UnitedStates::GovernmentBond);
>> >>>> >>
>> >>>> >>    Date settlementDate(19, September, 2012);
>> >>>> >>        // must be a business day
>> >>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>> >>>> >>
>> >>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> >>>> >> -fixingDays, Days);
>> >>>> >> cout << "Today is " << todaysDate << endl;
>> >>>> >>        // nothing to do with Date::todaysDate
>> >>>> >>        Settings::instance().evaluationDate() = todaysDate;
>> >>>> >>
>> >>>> >> =============discount factor
>> >>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>> >>>> >> compounding
>> >>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>> >>>> >> <[hidden email]>
>> >>>> >> wrote:
>> >>>> >>>
>> >>>> >>> Steve,
>> >>>> >>>    InterpolatedZeroCurve expects continuously compounded zero
>> >>>> >>> rates,
>> >>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as such.
>> >>>> >>> When
>> >>>> >>> you
>> >>>> >
>> >>>> >>> later ask for the index fixing, the code calculates the
>> >>>> >>> corresponding
>> >>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re
>> >>>> >>> seeing
>> >>>> >>> (it&apos;s
>> >>>> >
>> >>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>> >>>> >>> weeks
>> >>>> >>> in your case and r1 = 0.00105).  You can try converting your
>> >>>> >>> 0.00105
>> >>>> >>> to the correspondingly continuously compounded rate (same formula
>> >>>> >>> as
>> >>>> >>> above, but inverted) and pass that one to the curve.
>> >>>> >>>
>> >>>> >>> However, this will work only as long as the rate is constant. If
>> >>>> >>> the
>> >>>> >>> forecast index fixings vary in time, the zero rates will no
>> >>>> >>> longer
>> >>>> >>> be
>> >>>> >>> the same as the index rates, even converting the compounding (the
>> >>>> >>> zero
>> >>>> >>> rates are the average of the forward rates).  You&apos;d be much
>> >>>> >>> better
>> >>>> >>> off
>> >>>> >
>> >>>> >>> if your system could give you, for instance, sampled discount
>> >>>> >>> factors
>> >>>> >>> at the same dates. Otherwise you&apos;ll have to figure out the
>> >>>> >>> zero
>> >>>> >>> rates
>> >>>> >
>> >>>> >>> or the discount factors yourself.
>> >>>> >>>
>> >>>> >>> Hope this helps,
>> >>>> >>>    Luigi
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> >>>> >>> <[hidden email]> wrote:
>> >>>> >>> > Steve,
>> >>>> >>> >    may you send the data files you&apos;re using so that we can
>> >>>> >>> > actually
>> >>>> >
>> >>>> >>> > run your code?
>> >>>> >>> >
>> >>>> >>> > Luigi
>> >>>> >>> >
>> >>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]>
>> >>>> >>> > wrote:
>> >>>> >>> >> Luigi,
>> >>>> >>> >>
>> >>>> >>> >> I tried to use IborIndex to price the floating note. The
>> >>>> >>> >> result
>> >>>> >>> >> is
>> >>>> >>> >> about
>> >>>> >>> >> 0.0036% off from the correct answer. There are many factors
>> >>>> >>> >> that
>> >>>> >>> >> contribute
>> >>>> >>> >> to this discrepancy. But I think the main reason is that the
>> >>>> >>> >> forecastfixing
>> >>>> >>> >> is about 0.013% off from the index rate. Below are the code
>> >>>> >>> >> printing
>> >>>> >>> >> out
>> >>>> >>> >> forecastfixing and some of the index rate:
>> >>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >>>> >>> >> AccuralStart[i] <
>> >>>> >>> >> settlementDate){
>> >>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>> >>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>> >>>> >>> >> << "
>> >>>> >>> >> +++ " << IndexRate[i] << endl;
>> >>>> >>> >> }
>> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >>>> >>> >> AccuralStart[i] >=
>> >>>> >>> >> settlementDate){
>> >>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>> >>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>> >>>> >>> >> IndexRate[i]
>> >>>> >>> >> <<
>> >>>> >>> >> endl;
>> >>>> >>> >> }
>> >>>> >>> >> }
>> >>>> >>> >>
>> >>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >>>> >>> >>
>> >>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about
>> >>>> >>> >> the
>> >>>> >>> >> index
>> >>>> >>> >> rate
>> >>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>> >>>> >>> >> maturity
>> >>>> >>> >> date. Can you or anyone to help me to understand where
>> >>>> >>> >> 0.00000014
>> >>>> >>> >> comes
>> >>>> >>> >> from?
>> >>>> >>> >>
>> >>>> >>> >> Thanks
>> >>>> >>> >>
>> >>>> >>> >>
>> >>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >>>> >>> >> <[hidden email]>
>> >>>> >>> >> wrote:
>> >>>> >>> >>>
>> >>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]>
>> >>>> >>> >>> wrote:
>> >>>> >>> >>> > I am trying to price a floating rate bond that depends on
>> >>>> >>> >>> > the
>> >>>> >>> >>> > rate
>> >>>> >>> >>> > of a
>> >>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date
>> >>>> >>> >>> > are
>> >>>> >>> >>> > imported
>> >>>> >>> >>> > from
>> >>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>> >>>> >>> >>> > instrument.
>> >>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>> >>>> >>> >>> > questions on
>> >>>> >>> >>> > this
>> >>>> >>> >>> > topic:
>> >>>> >>> >>> >
>> >>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>> >>>> >>> >>> > instrument,
>> >>>> >>> >>> > like
>> >>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>> >>>> >>> >>>
>> >>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided
>> >>>> >>> >>> that
>> >>>> >>> >>> the
>> >>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>> >>>> >>> >>> compounded,
>> >>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>> >>>> >>> >>> LIBOR.  As
>> >>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the
>> >>>> >>> >>> rate
>> >>>> >>> >>> of
>> >>>> >>> >>> your Treasury instrument derived from that?  And instead of
>> >>>> >>> >>> looking
>> >>>> >>> >>> at
>> >>>> >>> >>> the price of the bond (that is, at the sum of the coupons,
>> >>>> >>> >>> which
>> >>>> >>> >>> muddies things), have you tried first looking at forecast
>> >>>> >>> >>> IborIndex
>> >>>> >>> >>> fixings to see if they match the rates you expect?
>> >>>> >>> >>>
>> >>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>> >>>> >>> >>> > TreasuryIndex by
>> >>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>> >>>> >>> >>> > building
>> >>>> >>> >>> > TreasuryIndex?
>> >>>> >>> >>>
>> >>>> >>> >>> You would have to implement the forecastFixing method so that
>> >>>> >>> >>> it
>> >>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be
>> >>>> >>> >>> able
>> >>>> >>> >>> to
>> >>>> >>> >>> forecast
>> >>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>> >>>> >>> >>> implement
>> >>>> >>> >>> the
>> >>>> >>> >>> maturityDate method, but that&apos;s easy).
>> >>>> >
>> >>>> >>> >>>
>> >>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument
>> >>>> >>> >>> > by
>> >>>> >>> >>> > tweaking
>> >>>> >>> >>> > the
>> >>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>> >>>> >>> >>>
>> >>>> >>> >>> See above. It depends on how much the conventions differ.
>> >>>> >>> >>>
>> >>>> >>> >>> > 4      Can someone point me to the right direction on how
>> >>>> >>> >>> > to
>> >>>> >>> >>> > leverage
>> >>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>> >>>> >>> >>> > Treasury
>> >>>> >>> >>> > instrument as the index after a peek at the code?
>> >>>> >>> >>>
>> >>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>> >>>> >>> >>> shouldn&apos;t
>> >>>> >
>> >>>> >>> >>> be that difficult. Once you have a rate class, you should be
>> >>>> >>> >>> able to
>> >>>> >>> >>> use the existing classes as you did in your code.
>> >>>> >>> >>>
>> >>>> >>> >>> Let me know how it works.
>> >>>> >>> >>>
>> >>>> >>> >>> Later,
>> >>>> >>> >>>    Luigi
>> >>>> >>> >>>
>> >>>> >>> >>>
>> >>>> >>> >>> --
>> >>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>> >>>> >>> >>> <https://twitter.com/lballabio>
>> >>>> >>> >>
>> >>>> >>> >>
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>> > --
>> >>>> >>> > <https://implementingquantlib.blogspot.com/>
>> >>>> >>> > <https://twitter.com/lballabio>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> --
>> >>>> >>> <https://implementingquantlib.blogspot.com/>
>> >>>> >>> <https://twitter.com/lballabio>
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > <https://implementingquantlib.blogspot.com/>
>> >>>> > <https://twitter.com/lballabio>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > ------------------------------------------------------------------------------
>> >>>> > October Webinars: Code for Performance
>> >>>> > Free Intel webinars can help you accelerate application
>> >>>> > performance.
>> >>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> >>>> > most
>> >>>> > from
>> >>>> > the latest Intel processors and coprocessors. See abstracts and
>> >>>> > register >
>> >>>> >
>> >>>> >
>> >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > QuantLib-users mailing list
>> >>>> > [hidden email]
>> >>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> <https://implementingquantlib.blogspot.com>
>> >>>> <https://twitter.com/lballabio>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>



--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

The coupons are instances of the IborCoupon class.  The value of the
coupon depends on the value of the underlying index fixing, whose
calculation is implemented in the IborCoupon::indexFixing method.
There you'll see the logic that chooses whether to forecast the Libor
rate or to retrieve it from past fixings.

More details on coupons in general are in chapter 4 at
<http://implementingquantlib.blogspot.com/p/the-book.html>.

Luigi


On Fri, Dec 6, 2013 at 1:57 AM, Steve <[hidden email]> wrote:

> Luigi, can you elaborate more about your point? Which class(es) can help me
> to understand how QuantLib to pick the curve before the evaluation date for
> calculating the first coupon payment after the evaluation date?
>
> Thanks
>
>
> On Thu, Nov 28, 2013 at 5:15 AM, Luigi Ballabio <[hidden email]>
> wrote:
>>
>> When is the first coupon fixed? If it fixes before the evaluation
>> date, it won't use the curve at all. It will use the fixings stored in
>> the IndexManager instead.
>>
>> Luigi
>>
>> On Thu, Nov 28, 2013 at 3:38 AM, Steve <[hidden email]> wrote:
>> > More one approach B
>> > ////////           Approach B
>> > If you want to keep your zero-rate data as given, that is, if you want
>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> > as you gave to the interpolated curve, you'll have to rebuild your
>> > curve; that is, remove the data before 09/17/12, add a new data point
>> > at 09/17/12 as the first point, and rebuild your curve.
>> > ////////////
>> >
>> > The problem with this approach is that the curve will not be exposed to
>> > the
>> > rates before 09/17/12 because the data before 09/17/12 is removed.
>> > Because
>> > the data before 09/17/12 is not available, the QuantLib will derive the
>> > first coupon payment based on the rates after 09/17/12. The result is
>> > that
>> > the first coupon is noticeably less the correct coupon because the rates
>> > before 09/17/12 is lower than that after 09/17/12.
>> >
>> > It seems that both approach A and B have the same issue that the rate
>> > before
>> > evaluation date is not used for computing the first coupon. Maybe I
>> > didn't
>> > do something right.
>> >
>> > Thank you for your help.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Nov 19, 2013 at 5:42 PM, Luigi Ballabio
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Ok, I finally managed to look at your code.
>> >>
>> >> Approach A: the curve moves, and you can see it from the fact that the
>> >> NPV changes, but the bond price doesn't change because the engine
>> >> always discounts to the settlement date of the bond.  If you move the
>> >> evaluation date so that the settlement date is the one you want, you
>> >> will see the price move as well.
>> >>
>> >> Approach B: you're probably trying to get rates (or discounts) between
>> >> the evaluation date and the start of the zero curve, although finding
>> >> out exactly why would require some time with a debugger. I suspect
>> >> that the settlement date of the bond is before the start of the curve,
>> >> since you're setting settlementDays = 1.  Since you want the discount
>> >> to be 1 on the 18th, and with settlementDays = 1, you probably want to
>> >> set the evaluation date to the 17th. You don't have to worry about
>> >> when the interest starts accruing: that info is contained into the
>> >> coupons, and the bond will take it into account when calculating the
>> >> accrued amount.
>> >>
>> >> Luigi
>> >>
>> >>
>> >>
>> >> On Sun, Nov 10, 2013 at 3:37 AM, Steve <[hidden email]> wrote:
>> >> > More on approach A
>> >> > /////    approach A
>> >> > Finally, if you want to change the evaluation date but keep the
>> >> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>> >> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>> >> > same as in the original curve) you can use the ImpliedTermStructure
>> >> > class. It takes the original curve and a new reference date, and
>> >> > builds a curve with the property above.
>> >> > //////
>> >> >
>> >> > With the approach A, I used to term structures in the program,
>> >> > TB13WksRateTermStructure, which is basically the original index rate,
>> >> > is
>> >> > used in calling FloatingRateBond FRN whose evaluation date is
>> >> > 07/31/12.
>> >> > discountRateTermStructureImplied is
>> >> > (TB13WksRateTermStructure+Discount
>> >> > Margin) that is used in FRN.setPricingEngine(FRNEngine) and its
>> >> > evaluation
>> >> > date is 09/13/12. But setting the evaluation date for
>> >> > discountRateTermStructureImplied doesn't make any difference for the
>> >> > final
>> >> > results, as shown below:
>> >> > ---------------------------Date(13, September, 2012)
>> >> > boost::shared_ptr<YieldTermStructure>
>> >> > discountRateTermStructureImplied(new
>> >> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
>> >> > September, 2012)));
>> >> > --Today is September 13th, 2012
>> >> > FRN Net present value1000267.9088
>> >> >    FRN Clean price99.999275416
>> >> >    FRN Dirty price100.02740216
>> >> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> >> > Actual/360 simple compounding
>> >> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> >> > 0  D  discountRateTermStructureImplied->zeroRate: September 13th,
>> >> > 2012 |
>> >> > 0.220000 % Actual/360 simple compounding
>> >> > 0  D  discountRateTermStructureImplied->discount: September 13th,
>> >> > 2012 |
>> >> > 1
>> >> >
>> >> > --------------------------------Date(31, July, 2012)
>> >> > boost::shared_ptr<YieldTermStructure>
>> >> > discountRateTermStructureImplied(new
>> >> > ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31,
>> >> > July,
>> >> > 2012)));
>> >> > Today is September 13th, 2012
>> >> > FRN Net present value999998.98404
>> >> >    FRN Clean price99.999275416
>> >> >    FRN Dirty price100.02740216
>> >> > 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
>> >> > Actual/360 simple compounding
>> >> > 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
>> >> > 0  D  discountRateTermStructureImplied->zeroRate: July 31st, 2012 |
>> >> > 0.215000
>> >> > % Actual/360 simple compounding
>> >> > 0  D  discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>> >> >
>> >> >
>> >> > It seems that it doesn't make difference in the price on which term
>> >> > structure the priceEngine links to. How can that be? May be the
>> >> > priceEngine
>> >> > automatically linked to the term structure defined by <IborIndex>
>> >> > when
>> >> > calling the FloatingRateBond?
>> >> >
>> >> >
>> >> > Thanks for your help.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Nov 7, 2013 at 7:52 PM, Steve <[hidden email]> wrote:
>> >> >>
>> >> >> more on approach B
>> >> >> ////////           Approach B
>> >> >> If you want to keep your zero-rate data as given, that is, if you
>> >> >> want
>> >> >> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >> >> same
>> >> >> as you gave to the interpolated curve, you'll have to rebuild your
>> >> >> curve; that is, remove the data before 09/17/12, add a new data
>> >> >> point
>> >> >> at 09/17/12 as the first point, and rebuild your curve.
>> >> >> ////////////
>> >> >>
>> >> >> the program will not error out with 'egative time (-0.0111111)
>> >> >> given'
>> >> >> and
>> >> >> give some result after the first date in the input index rate file
>> >> >> was
>> >> >> moved
>> >> >> from 09/18 to 09/13. But it is not right, because the discount
>> >> >> factor
>> >> >> should
>> >> >> be 1 on 09/18 not 09/13. The reason it doesn't error out once the
>> >> >> first
>> >> >> date
>> >> >> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is
>> >> >> due
>> >> >> to
>> >> >> the fact that the interested start to accrue on 09/13 not 09/18,
>> >> >> thought the
>> >> >> discount factor should be 1 on 09/18. This is because the instrument
>> >> >> used
>> >> >> for index rate is issued every Thursday.  So the dilemma is that the
>> >> >> date
>> >> >> when the interest accrual starts and the date where discount factor
>> >> >> equals
>> >> >> to 1 are different! That only invalidate the approach B. But I would
>> >> >> think
>> >> >> someone must have dealt this kind of dilemma long ago.
>> >> >>
>> >> >>
>> >> >> On Thu, Nov 7, 2013 at 12:22 AM, Steve <[hidden email]> wrote:
>> >> >>>
>> >> >>> Luigi,
>> >> >>>
>> >> >>> I was not able to make the program much smaller than it used to be.
>> >> >>> I
>> >> >>> simply removed the printing sections. I divided the code to two
>> >> >>> programs,
>> >> >>> one for the approach A and the other for the approach B. They are
>> >> >>> almost
>> >> >>> identical except that the approach B uses ASDateOriginal.dat and
>> >> >>> IndexRateOriginal.dat, the approach A removes any index before
>> >> >>> 9/18/12
>> >> >>> and
>> >> >>> use ImpliedTermStructure to set evaluation date for term structure
>> >> >>> used by
>> >> >>> floating rate note price engine to 09/13/12. Somehow, resetting the
>> >> >>> evaluation date doesn't make any difference in the result
>> >> >>>
>> >> >>> In the approach A, the program use 07/01/12 as the evaluation date
>> >> >>> for
>> >> >>> TB13WksRateTermStructure that is the input when calling
>> >> >>> FloatingRateBond
>> >> >>> FRN(...). the evaluation date for discountRateTermStructureImplied
>> >> >>> that is
>> >> >>> used in FRN.setPricingEngine. Actually, I am not sure that index
>> >> >>> structure
>> >> >>> in FRN and the term structure used in its price engine can have two
>> >> >>> different evaluation date. this approach erred out with 'negative
>> >> >>> time
>> >> >>> (-0.0111111) given'
>> >> >>>
>> >> >>> the program for A and B attached. also the data file for A and B
>> >> >>> are
>> >> >>> attached. B uses *original* files
>> >> >>>
>> >> >>> Thank you!
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Can you post a minimal program to replicate this?
>> >> >>>>
>> >> >>>> Luigi
>> >> >>>>
>> >> >>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <[hidden email]>
>> >> >>>> wrote:
>> >> >>>> > Luigi,
>> >> >>>> >
>> >> >>>> > Thank you very much for your time and help!
>> >> >>>> >
>> >> >>>> > /////    approach A
>> >> >>>> > Finally, if you want to change the evaluation date but keep the
>> >> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and
>> >> >>>> > to
>> >> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be
>> >> >>>> > the
>> >> >>>> > same as in the original curve) you can use the
>> >> >>>> > ImpliedTermStructure
>> >> >>>> > class. It takes the original curve and a new reference date, and
>> >> >>>> > builds a curve with the property above.
>> >> >>>> > //////
>> >> >>>> > I use two yield term structure. TB13WksRateTermStructure,
>> >> >>>> > basically
>> >> >>>> > is
>> >> >>>> > the
>> >> >>>> > zero rate of original file whose evaluation date is 7/31 because
>> >> >>>> > the
>> >> >>>> > original file starts with 7/31/12. Then I use
>> >> >>>> > ImpliedTermStructure
>> >> >>>> > to
>> >> >>>> > set
>> >> >>>> > the evaluation date to 09/18 to create another yield term
>> >> >>>> > structure,
>> >> >>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is
>> >> >>>> > the
>> >> >>>> > input for
>> >> >>>> > FloatingRateBond FRN and discountRateTermStructureImplied is
>> >> >>>> > linked
>> >> >>>> > to
>> >> >>>> > FRNEngine. But the result, dirty/clean price turns out to be the
>> >> >>>> > same
>> >> >>>> > as
>> >> >>>> > before the evaluation date of the yield term structured used for
>> >> >>>> > the
>> >> >>>> > engine
>> >> >>>> > was set to 09/18/12. Any way, it doesn't make difference on the
>> >> >>>> > price.
>> >> >>>> >
>> >> >>>> > ////////           Approach B
>> >> >>>> > If you want to keep your zero-rate data as given, that is, if
>> >> >>>> > you
>> >> >>>> > want
>> >> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >> >>>> > same
>> >> >>>> > as you gave to the interpolated curve, you'll have to rebuild
>> >> >>>> > your
>> >> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >> >>>> > point
>> >> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >> >>>> > ////////////
>> >> >>>> > I remove the data before 09/18/12 from both the index file and
>> >> >>>> > the
>> >> >>>> > accrual
>> >> >>>> > date file. But the program errored out with
>> >> >>>> > AccuralStartSize = 680
>> >> >>>> > IndexRateFileSize = 680
>> >> >>>> > negative time (-0.0111111) given
>> >> >>>> >
>> >> >>>> > I tried to locate where exactly the program failed. The closest
>> >> >>>> > I
>> >> >>>> > could get
>> >> >>>> > is
>> >> >>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate()
>> >> >>>> >> Line
>> >> >>>> >> 152
>> >> >>>> >> C++
>> >> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate()
>> >> >>>> > Line
>> >> >>>> > 155 C++
>> >> >>>> >   DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV()  Line
>> >> >>>> > 187 +
>> >> >>>> > 0xe
>> >> >>>> > bytes C++
>> >> >>>> >   DMCalc-evaluationDate.exe!main(int __formal, int __formal)
>> >> >>>> > Line
>> >> >>>> > 258
>> >> >>>> > + 0xb
>> >> >>>> > bytes C++
>> >> >>>> >   DMCalc-evaluationDate.exe!__tmainCRTStartup()  Line 555 + 0x19
>> >> >>>> > bytes
>> >> >>>> > C
>> >> >>>> >   DMCalc-evaluationDate.exe!mainCRTStartup()  Line 371 C
>> >> >>>> > it failed while calculate NPV().
>> >> >>>> >
>> >> >>>> > So my questions is why setting the evaluation date to 09/18 for
>> >> >>>> > the
>> >> >>>> > discount
>> >> >>>> > term structure used for price engine didn't make any difference
>> >> >>>> > on
>> >> >>>> > price and
>> >> >>>> > what could be possible reason that the approach B failed. Your
>> >> >>>> > help
>> >> >>>> > will be
>> >> >>>> > greatly appreciated.
>> >> >>>> >
>> >> >>>> > Best Regards,
>> >> >>>> > Steve
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > From: Luigi Ballabio <[hidden email]>
>> >> >>>> > To: Steve <[hidden email]>
>> >> >>>> > Cc: QuantLib users <[hidden email]>
>> >> >>>> > Sent: Friday, October 4, 2013 9:23 AM
>> >> >>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>> >> >>>> >
>> >> >>>> > Steve,
>> >> >>>> >     just setting the evaluation date doesn&apos;t work because
>> >> >>>> > if
>> >> >>>> > you
>> >> >>>> >
>> >> >>>> > specify a reference date for the curve, it overrides the
>> >> >>>> > evaluation
>> >> >>>> > date.  For InterpolatedZeroCurve, that&apos;s done implicitly by
>> >> >>>> > using
>> >> >>>> > the
>> >> >>>> >
>> >> >>>> > first passed date as reference date.  (For more info, see
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > <http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>> >> >>>> >
>> >> >>>> > Now, there are solutions for this, but there are different
>> >> >>>> > possible
>> >> >>>> > behaviors when moving the reference date (as you tried to do
>> >> >>>> > when
>> >> >>>> > changing the evaluation date) and you&apos;ll have to choose the
>> >> >>>> > solution
>> >> >>>> >
>> >> >>>> > based on the one you want.
>> >> >>>> >
>> >> >>>> > If you want to keep your zero-rate data as given, that is, if
>> >> >>>> > you
>> >> >>>> > want
>> >> >>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the
>> >> >>>> > same
>> >> >>>> > as you gave to the interpolated curve, you&apos;ll have to
>> >> >>>> > rebuild
>> >> >>>> > your
>> >> >>>> >
>> >> >>>> > curve; that is, remove the data before 09/17/12, add a new data
>> >> >>>> > point
>> >> >>>> > at 09/17/12 as the first point, and rebuild your curve.
>> >> >>>> >
>> >> >>>> > If you want to move the whole thing two months ahead (that is,
>> >> >>>> > to
>> >> >>>> > have
>> >> >>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the
>> >> >>>> > zero
>> >> >>>> > rate
>> >> >>>> > at 09/17/14 equal to the one you had at 07/31/14 before)
>> >> >>>> > you&apos;ll
>> >> >>>> > also
>> >> >>>> >
>> >> >>>> > have to rebuild your data set and build a new curve.  For other
>> >> >>>> > types
>> >> >>>> > of curves (not for InterpolatedZeroCurve, though) it&apos;s
>> >> >>>> > possible
>> >> >>>> > to
>> >> >>>> >
>> >> >>>> > have this done automatically when the evaluation date changes;
>> >> >>>> > see
>> >> >>>> > the
>> >> >>>> > link I&apos;ve posted above.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > Finally, if you want to change the evaluation date but keep the
>> >> >>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and
>> >> >>>> > to
>> >> >>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be
>> >> >>>> > the
>> >> >>>> > same as in the original curve) you can use the
>> >> >>>> > ImpliedTermStructure
>> >> >>>> > class. It takes the original curve and a new reference date, and
>> >> >>>> > builds a curve with the property above.
>> >> >>>> >
>> >> >>>> > Later,
>> >> >>>> >     Luigi
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <[hidden email]> wrote:
>> >> >>>> >> Luiqi,
>> >> >>>> >>
>> >> >>>> >> Thank you for your help. I found one of the root problems. I
>> >> >>>> >> used
>> >> >>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>> >> >>>> >> instance,
>> >> >>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>> >> >>>> >> However, I
>> >> >>>> >> intended to set 09/19/12 as the settlement date and I did so in
>> >> >>>> >> the
>> >> >>>> >> program
>> >> >>>> >> using Settings::instance().evaluationDate(). But I just found
>> >> >>>> >> out
>> >> >>>> >> that the
>> >> >>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit
>> >> >>>> >> off
>> >> >>>> >> in
>> >> >>>> >> discount factors and in turn in clean and dirty prices. Please
>> >> >>>> >> see
>> >> >>>> >> the
>> >> >>>> >> attachment for the program. I wonder why assigning Settings
>> >> >>>> >> doesn&apos;t
>> >> >>>> >> work. Do
>> >> >>>> >
>> >> >>>> >> I need to define YieldTermStructure instance with a specified
>> >> >>>> >> reference
>> >> >>>> >> date?
>> >> >>>> >>
>> >> >>>> >> ===========setting evaluation date
>> >> >>>> >> Natural settlementDays = 1;
>> >> >>>> >> Integer fixingDays = 4;
>> >> >>>> >>
>> >> >>>> >> DayCounter DMCalcCounter = Actual360();
>> >> >>>> >> Calendar DMCalccalendar =
>> >> >>>> >> UnitedStates(UnitedStates::GovernmentBond);
>> >> >>>> >>
>> >> >>>> >>    Date settlementDate(19, September, 2012);
>> >> >>>> >>        // must be a business day
>> >> >>>> >>        settlementDate = DMCalccalendar.adjust(settlementDate);
>> >> >>>> >>
>> >> >>>> >>        Date todaysDate = DMCalccalendar.advance(settlementDate,
>> >> >>>> >> -fixingDays, Days);
>> >> >>>> >> cout << "Today is " << todaysDate << endl;
>> >> >>>> >>        // nothing to do with Date::todaysDate
>> >> >>>> >>        Settings::instance().evaluationDate() = todaysDate;
>> >> >>>> >>
>> >> >>>> >> =============discount factor
>> >> >>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>> >> >>>> >> compounding
>> >> >>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>> >> >>>> >> <[hidden email]>
>> >> >>>> >> wrote:
>> >> >>>> >>>
>> >> >>>> >>> Steve,
>> >> >>>> >>>    InterpolatedZeroCurve expects continuously compounded zero
>> >> >>>> >>> rates,
>> >> >>>> >>> so the 0.00105 rate you&apos;re passing gets interpreted as
>> >> >>>> >>> such.
>> >> >>>> >>> When
>> >> >>>> >>> you
>> >> >>>> >
>> >> >>>> >>> later ask for the index fixing, the code calculates the
>> >> >>>> >>> corresponding
>> >> >>>> >>> simply compounded rate, which is the 0.00105014 you&apos;re
>> >> >>>> >>> seeing
>> >> >>>> >>> (it&apos;s
>> >> >>>> >
>> >> >>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T =
>> >> >>>> >>> 13
>> >> >>>> >>> weeks
>> >> >>>> >>> in your case and r1 = 0.00105).  You can try converting your
>> >> >>>> >>> 0.00105
>> >> >>>> >>> to the correspondingly continuously compounded rate (same
>> >> >>>> >>> formula
>> >> >>>> >>> as
>> >> >>>> >>> above, but inverted) and pass that one to the curve.
>> >> >>>> >>>
>> >> >>>> >>> However, this will work only as long as the rate is constant.
>> >> >>>> >>> If
>> >> >>>> >>> the
>> >> >>>> >>> forecast index fixings vary in time, the zero rates will no
>> >> >>>> >>> longer
>> >> >>>> >>> be
>> >> >>>> >>> the same as the index rates, even converting the compounding
>> >> >>>> >>> (the
>> >> >>>> >>> zero
>> >> >>>> >>> rates are the average of the forward rates).  You&apos;d be
>> >> >>>> >>> much
>> >> >>>> >>> better
>> >> >>>> >>> off
>> >> >>>> >
>> >> >>>> >>> if your system could give you, for instance, sampled discount
>> >> >>>> >>> factors
>> >> >>>> >>> at the same dates. Otherwise you&apos;ll have to figure out
>> >> >>>> >>> the
>> >> >>>> >>> zero
>> >> >>>> >>> rates
>> >> >>>> >
>> >> >>>> >>> or the discount factors yourself.
>> >> >>>> >>>
>> >> >>>> >>> Hope this helps,
>> >> >>>> >>>    Luigi
>> >> >>>> >>>
>> >> >>>> >>>
>> >> >>>> >>>
>> >> >>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>> >> >>>> >>> <[hidden email]> wrote:
>> >> >>>> >>> > Steve,
>> >> >>>> >>> >    may you send the data files you&apos;re using so that we
>> >> >>>> >>> > can
>> >> >>>> >>> > actually
>> >> >>>> >
>> >> >>>> >>> > run your code?
>> >> >>>> >>> >
>> >> >>>> >>> > Luigi
>> >> >>>> >>> >
>> >> >>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <[hidden email]>
>> >> >>>> >>> > wrote:
>> >> >>>> >>> >> Luigi,
>> >> >>>> >>> >>
>> >> >>>> >>> >> I tried to use IborIndex to price the floating note. The
>> >> >>>> >>> >> result
>> >> >>>> >>> >> is
>> >> >>>> >>> >> about
>> >> >>>> >>> >> 0.0036% off from the correct answer. There are many factors
>> >> >>>> >>> >> that
>> >> >>>> >>> >> contribute
>> >> >>>> >>> >> to this discrepancy. But I think the main reason is that
>> >> >>>> >>> >> the
>> >> >>>> >>> >> forecastfixing
>> >> >>>> >>> >> is about 0.013% off from the index rate. Below are the code
>> >> >>>> >>> >> printing
>> >> >>>> >>> >> out
>> >> >>>> >>> >> forecastfixing and some of the index rate:
>> >> >>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>> >> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >> >>>> >>> >> AccuralStart[i] <
>> >> >>>> >>> >> settlementDate){
>> >> >>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>> >> >>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>> >> >>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>> >> >>>> >>> >> << "
>> >> >>>> >>> >> +++ " << IndexRate[i] << endl;
>> >> >>>> >>> >> }
>> >> >>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>> >> >>>> >>> >> AccuralStart[i] >=
>> >> >>>> >>> >> settlementDate){
>> >> >>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>> >> >>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>> >> >>>> >>> >> IndexRate[i]
>> >> >>>> >>> >> <<
>> >> >>>> >>> >> endl;
>> >> >>>> >>> >> }
>> >> >>>> >>> >> }
>> >> >>>> >>> >>
>> >> >>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>> >> >>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>> >> >>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>> >> >>>> >>> >>
>> >> >>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about
>> >> >>>> >>> >> the
>> >> >>>> >>> >> index
>> >> >>>> >>> >> rate
>> >> >>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to
>> >> >>>> >>> >> the
>> >> >>>> >>> >> maturity
>> >> >>>> >>> >> date. Can you or anyone to help me to understand where
>> >> >>>> >>> >> 0.00000014
>> >> >>>> >>> >> comes
>> >> >>>> >>> >> from?
>> >> >>>> >>> >>
>> >> >>>> >>> >> Thanks
>> >> >>>> >>> >>
>> >> >>>> >>> >>
>> >> >>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>> >> >>>> >>> >> <[hidden email]>
>> >> >>>> >>> >> wrote:
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <[hidden email]>
>> >> >>>> >>> >>> wrote:
>> >> >>>> >>> >>> > I am trying to price a floating rate bond that depends
>> >> >>>> >>> >>> > on
>> >> >>>> >>> >>> > the
>> >> >>>> >>> >>> > rate
>> >> >>>> >>> >>> > of a
>> >> >>>> >>> >>> > Treasury instrument. For simplicity, the rate and the
>> >> >>>> >>> >>> > date
>> >> >>>> >>> >>> > are
>> >> >>>> >>> >>> > imported
>> >> >>>> >>> >>> > from
>> >> >>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>> >> >>>> >>> >>> > instrument.
>> >> >>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>> >> >>>> >>> >>> > questions on
>> >> >>>> >>> >>> > this
>> >> >>>> >>> >>> > topic:
>> >> >>>> >>> >>> >
>> >> >>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>> >> >>>> >>> >>> > instrument,
>> >> >>>> >>> >>> > like
>> >> >>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> Not as such.  You might use IborIndex as a proxy, provided
>> >> >>>> >>> >>> that
>> >> >>>> >>> >>> the
>> >> >>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>> >> >>>> >>> >>> compounded,
>> >> >>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>> >> >>>> >>> >>> LIBOR.  As
>> >> >>>> >>> >>> far as I know, T-bills are quoted as a discount; how is
>> >> >>>> >>> >>> the
>> >> >>>> >>> >>> rate
>> >> >>>> >>> >>> of
>> >> >>>> >>> >>> your Treasury instrument derived from that?  And instead
>> >> >>>> >>> >>> of
>> >> >>>> >>> >>> looking
>> >> >>>> >>> >>> at
>> >> >>>> >>> >>> the price of the bond (that is, at the sum of the coupons,
>> >> >>>> >>> >>> which
>> >> >>>> >>> >>> muddies things), have you tried first looking at forecast
>> >> >>>> >>> >>> IborIndex
>> >> >>>> >>> >>> fixings to see if they match the rates you expect?
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> > 2 if the answer is no, is it possible to build a class
>> >> >>>> >>> >>> > like
>> >> >>>> >>> >>> > TreasuryIndex by
>> >> >>>> >>> >>> > extending InterestRateIndex? What would be the challenge
>> >> >>>> >>> >>> > in
>> >> >>>> >>> >>> > building
>> >> >>>> >>> >>> > TreasuryIndex?
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> You would have to implement the forecastFixing method so
>> >> >>>> >>> >>> that
>> >> >>>> >>> >>> it
>> >> >>>> >>> >>> returns the T-Bill rate. Basically, you&apos;d have to be
>> >> >>>> >>> >>> able
>> >> >>>> >>> >>> to
>> >> >>>> >>> >>> forecast
>> >> >>>> >>> >>> the rate off your treasury curve. (You&apos;d also have to
>> >> >>>> >>> >>> implement
>> >> >>>> >>> >>> the
>> >> >>>> >>> >>> maturityDate method, but that&apos;s easy).
>> >> >>>> >
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury
>> >> >>>> >>> >>> > instrument
>> >> >>>> >>> >>> > by
>> >> >>>> >>> >>> > tweaking
>> >> >>>> >>> >>> > the
>> >> >>>> >>> >>> > calendar alone? What else needs to be done to make it
>> >> >>>> >>> >>> > work?
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> See above. It depends on how much the conventions differ.
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> > 4      Can someone point me to the right direction on
>> >> >>>> >>> >>> > how
>> >> >>>> >>> >>> > to
>> >> >>>> >>> >>> > leverage
>> >> >>>> >>> >>> > QuantLib classes to price a floating rate bond that uses
>> >> >>>> >>> >>> > a
>> >> >>>> >>> >>> > Treasury
>> >> >>>> >>> >>> > instrument as the index after a peek at the code?
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> If using IborIndex fails, inheriting from
>> >> >>>> >>> >>> InterestRateIndex
>> >> >>>> >>> >>> shouldn&apos;t
>> >> >>>> >
>> >> >>>> >>> >>> be that difficult. Once you have a rate class, you should
>> >> >>>> >>> >>> be
>> >> >>>> >>> >>> able to
>> >> >>>> >>> >>> use the existing classes as you did in your code.
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> Let me know how it works.
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> Later,
>> >> >>>> >>> >>>    Luigi
>> >> >>>> >>> >>>
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> --
>> >> >>>> >>> >>> <https://implementingquantlib.blogspot.com/>
>> >> >>>> >>> >>> <https://twitter.com/lballabio>
>> >> >>>> >>> >>
>> >> >>>> >>> >>
>> >> >>>> >>> >
>> >> >>>> >>> >
>> >> >>>> >>> >
>> >> >>>> >>> > --
>> >> >>>> >>> > <https://implementingquantlib.blogspot.com/>
>> >> >>>> >>> > <https://twitter.com/lballabio>
>> >> >>>> >>>
>> >> >>>> >>>
>> >> >>>> >>>
>> >> >>>> >>> --
>> >> >>>> >>> <https://implementingquantlib.blogspot.com/>
>> >> >>>> >>> <https://twitter.com/lballabio>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > --
>> >> >>>> > <https://implementingquantlib.blogspot.com/>
>> >> >>>> > <https://twitter.com/lballabio>
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > ------------------------------------------------------------------------------
>> >> >>>> > October Webinars: Code for Performance
>> >> >>>> > Free Intel webinars can help you accelerate application
>> >> >>>> > performance.
>> >> >>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>> >> >>>> > the
>> >> >>>> > most
>> >> >>>> > from
>> >> >>>> > the latest Intel processors and coprocessors. See abstracts and
>> >> >>>> > register >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> >> >>>> >
>> >> >>>> > _______________________________________________
>> >> >>>> > QuantLib-users mailing list
>> >> >>>> > [hidden email]
>> >> >>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >> >>>> >
>> >> >>>> >
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> <https://implementingquantlib.blogspot.com>
>> >> >>>> <https://twitter.com/lballabio>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> <https://implementingquantlib.blogspot.com>
>> >> <https://twitter.com/lballabio>
>> >
>> >
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users