|
From: Peter C. <pca...@gm...> - 2018-07-31 19:18:31
|
Hi Francois,
yes I think so, the FraRateHelper assumes a simply compounded rate always. However, to use the FRA helper with different compounding conventions you can easily convert to simple compounding using the InterestRate class before feeding the quote into the helper? Or write a new rate helper that accepts any such rate?
But this is not directly comparable to setting up an InterpolatedForwardCurve, is it? If you want a version of an InterpolatedForwardCurve that floats with the global evaluation date, why not implement this directly, replacing the fixed dates in InterpolatedForwardCurve with Periods or calendar days or something like that and updating the interpolation grid on changes of the evaluation date?
Best Regards
Peter
> On 30 Jul 2018, at 21:57, Francois Botha <ig...@gm...> wrote:
>
> Hi Peter,
>
> Maybe some context. I was looking at the FraRateHelper class and I see that it uses an instance of IborIndex. Is the assumption of a linear compound rate valid for the FraRateHelper classes too?
>
> My ultimate goal is to create my own subclass of RateHelper that accepts a quote of a forward rate, start date and end date so that I can build a PiecewiseYieldCurve and pass this new ratehelper subclass. See my other post about this. If that assumption about the IborIndex is always true, then I won't be able to use it.
>
> thanks
> Francois Botha
>
>
> On Mon, 30 Jul 2018 at 21:34, Peter Caspers <pca...@gm... <mailto:pca...@gm...>> wrote:
> Hi Francois,
>
> let’s be a bit careful changing this ;-) … this computes a projected fixing of an Ibor Index which by definition is a simply (linearly) compounded rate r. The forward compound factor between d1 and d2 is therefore
>
> 1 + r * yearFraction(d1, d2)
>
> The same compound factor in terms of discount factors (and therefore independent of any rate conventions) is given by disc1 / disc2, from which the return value formula follows.
>
> Best Regards
> Peter
>
>
>
>> On 30 Jul 2018, at 13:02, Francois Botha <ig...@gm... <mailto:ig...@gm...>> wrote:
>>
>> Hi,
>>
>> I notice this code:
>>
>> inline Rate IborIndex::forecastFixing(const Date& d1,
>> const Date& d2,
>> Time t) const {
>> QL_REQUIRE(!termStructure_.empty(),
>> "null term structure set to this instance of " << name());
>> DiscountFactor disc1 = termStructure_->discount(d1);
>> DiscountFactor disc2 = termStructure_->discount(d2);
>> return (disc1/disc2 - 1.0) / t;
>> }
>>
>> The last line looks odd to me. disc1/disc would return a non-continuously compounded return. Dividing by t is the approach to annualise continuous returns. So the 2 are not consistent.
>>
>> I would have expected:
>> return std::pow(disc1 / disc2, 1 / t) - 1.0;
>>
>> On the other hand, if I make that change, many tests fail, so I'm by no means confident about my assertion above.
>>
>> regards
>> Francois Botha
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>
>> QuantLib-dev mailing list
>> Qua...@li... <mailto:Qua...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>
|