Re: pricing a floating rate bond

Posted by Steve on
URL: http://quantlib.414.s1.nabble.com/pricing-a-floating-rate-bond-tp14445p14678.html

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