|
From: Francois B. <ig...@gm...> - 2018-08-06 11:16:45
|
Thanks, Peter.
This is what Luigi also suggested and yes, now it seems like the easier
route.
I appreciate the help.
Francois Botha
On Tue, 31 Jul 2018 at 21:18, Peter Caspers <pca...@gm...> wrote:
> 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...>
> 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...> 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_______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>>
>
|