From: Luigi B. <lui...@gm...> - 2013-11-04 08:39:34
|
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'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 <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'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'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 >>> <lui...@gm...> 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 <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'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 > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-users > > -- <https://implementingquantlib.blogspot.com> <https://twitter.com/lballabio> |