Add GenericRateHelper extending RelativeDateRateHelper#2565
Conversation
|
Hi, are there any updates or notes on this PR? |
|
Not yet but I will have notes. I'll get to these PRs when I find some time. |
| compounding_, frequency_, extrapolate_); | ||
| } | ||
|
|
||
| void GenericRateHelper::initializeDates() {} |
There was a problem hiding this comment.
Since you don't do anything when evaluationDate changes, you don't need to inherit from RelativeDateRateHelper.
|
@ArsenP0doba please explain what this is and how this is intended to be used. It may be good to find a more descriptive name than calling it "generic". |
| class GenericRateHelper : public RelativeDateRateHelper { | ||
| public: | ||
| GenericRateHelper(const Handle<Quote>& rate, | ||
| const Date& settlementDate, |
There was a problem hiding this comment.
settlementDate is not used. (just setting earliestDate_ doesn't have any effect)
| Real impliedQuote() const override; | ||
|
|
||
| protected: | ||
| DayCounter dayCounter_; |
There was a problem hiding this comment.
Is there a reason to make dayCounter_ protected but all other fields and initializeDates private?
|
I, too, would like to understand the use case. If it's "a curve built by specifying a set of zero-rates that can change", it's probably a better fit for an extension of |
|
@lballabio @eltoder By way of context, these changes were originally made in our internal QuantLib copy, which was based on QuantLib 1.4. The main reason for introducing concrete implementations was Java/SWIG usage: our understanding was that, in order to expose and use these behaviours cleanly from Java, we needed these implementations rather than relying only on more generic C++ constructs. Since a long time has passed, we will review the individual comments carefully and check whether newer QuantLib functionality already covers some of the use cases. We will comment point by point later, clarifying where Java/SWIG exposure is still the reason behind the proposed design. |
4 participants
No description provided.