http://quantlib.414.s1.nabble.com/pricing-a-floating-rate-bond-tp14445p14552.html
date. For InterpolatedZeroCurve, that's done implicitly by using the
first passed date as reference date. (For more info, see
have to rebuild your data set and build a new curve. For other types
class. It takes the original curve and a new reference date, and
> 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>
>
>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >