Re: [Quantlib-users] pricing a floating rate bond

[Luigi B. <lui...@gm...>]

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 <xu...@gm...> 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 <lui...@gm...>
> 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 <xu...@gm...> 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
>> > <lui...@gm...>
>> > 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 <xu...@gm...> 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 <xu...@gm...> 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 <xu...@gm...> 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
>> >> >>> <lui...@gm...>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Can you post a minimal program to replicate this?
>> >> >>>>
>> >> >>>> Luigi
>> >> >>>>
>> >> >>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <xug...@ya...>
>> >> >>>> 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 <lui...@gm...>
>> >> >>>> > To: Steve <xu...@gm...>
>> >> >>>> > Cc: QuantLib users <qua...@li...>
>> >> >>>> > 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 <xu...@gm...> 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
>> >> >>>> >> <lui...@gm...>
>> >> >>>> >> 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
>> >> >>>> >>> <lui...@gm...> 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 <xu...@gm...>
>> >> >>>> >>> > 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
>> >> >>>> >>> >> <lui...@gm...>
>> >> >>>> >>> >> wrote:
>> >> >>>> >>> >>>
>> >> >>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <xu...@gm...>
>> >> >>>> >>> >>> 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
>> >> >>>> > Qua...@li...
>> >> >>>> > 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>