http://quantlib.414.s1.nabble.com/pricing-a-floating-rate-bond-tp14445p14680.html
date, it won't use the curve at all. It will use the fixings stored in
> 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'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>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> <
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
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!