Add Cubic__* interpolations and LinearThenFlat interpolation #2566
Add Cubic__* interpolations and LinearThenFlat interpolation #2566ArsenP0doba wants to merge 2 commits into
Conversation
|
Hi, are there any updates or notes on this PR? |
|
|
||
| } | ||
|
|
||
| class Cubic__FritschButland_nonMonotonic : public Cubic { |
There was a problem hiding this comment.
Do we really need to add a class for every combination of constructor arguments in Cubic? Why not just use Cubic directly and pass any arguments that you like?
| } | ||
|
|
||
| //! %Linear-then-flat interpolation between discrete points | ||
| class LinearThenFlatInterpolation : public Interpolation { |
There was a problem hiding this comment.
It will probably be less work to implement this using the existing MixedInterpolation in ql/math/interpolations/mixedinterpolation.hpp
You can switch between Linear and ForwardFlat or BackwardFlat.
| template <class I1, class I2> | ||
| LinearThenFlatInterpolation(const I1& xBegin, | ||
| const I1& xEnd, | ||
| const I2& yBegin) { |
There was a problem hiding this comment.
You need to pass a switch point like MixedLinearCubic does. Right now your code switches after xEnd-xBegin points, i.e. after the end of the data. So it's always linear.
There was a problem hiding this comment.
I think it's intentional. It's not a mixed interpolation, it's a linear interpolation with flat extrapolation (am I right, @ArsenP0doba?)
If that's the case, though (and it's a legitimate use case, I think), we should probably think of a way to specify the extrapolation type for a generic interpolation, instead of having classes like LinearThenFlat, CubicThanFlat etc.
There was a problem hiding this comment.
In that case, can't this already be done with the FlatExtrapolator class?
There was a problem hiding this comment.
Right, I was thinking of something like FlatExtrapolator but I didn't remember we have it already :)
There was a problem hiding this comment.
However, FlatExtrapolator is not always useable out of the box, for instance with PiecewiseYieldCurve. We should probably add the missing bits.
There was a problem hiding this comment.
@lballabio ah yes, we are missing a factory class for it.
|
@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. |
|
@RobertoSoft you no longer need to create these classes for swig. I exposed a generic cubic interpolation that accepts any arguments you want. Please see lballabio/QuantLib-SWIG#824 |
4 participants
No description provided.