>).
based on the one you want.
at 09/17/12 as the first point, and rebuild your curve.
link I've posted
above.
class. It takes the original curve and a new reference date, and
builds a curve with the property above.
> 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>
>
>
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 >