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 resultIn 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* filesThank 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
>
>
| Free forum by Nabble | Edit this page |