Inconsistency in Day Count in Index Curve? about financepy HOT 3 OPEN

I think this is true only when a discount curve is instantiated as the base class, i.e. discount_curve.py, in which you define your own method for interpolation from interpolator.py. Although I agree that this can cause mistmaches between day count types, I think it's likely not affecting the vast majority of the use cases.

Normally, you instantiate discount curves like:

1. discount_curve_flat.py
2. discount_curve_zeros.py
3. discount_curve_poly.py

In the example we're discussing some weeks ago (issue #188), when I put a breakpoint in index.df(endAccruedDt) and step into, I get the correct day_count convention for float_leg, because discount_curve_flat.py overrides the base self.df method to its own (see image below).

Of course, since I wasn't responsible for the design of the discount curves, I'd appreciate if @domokane gave his views on this.

Best,
Matheus

from financepy.

Hi, thanks for look at this. I think we are both correct, it depends on whether the child classes override the implementation of df.

I was looking at IborSingleCurve class which is initialized from basket of deposit and IRS, which is common and useful in use cases related to curve construction and CDS survival curve calibration. Examples are the following notebooks,

1. FINCDS_ValuingCDSCompareToMarkit.ipynb
2. FINIBORSINGLECURVE_BuildingASimpleIborCurve.ipynb

With typical usage like

dcType = DayCountTypes.ACT_360
depo1 = IborDeposit(settlement_date, "1M", 0.017156, dcType)
depo2 = IborDeposit(settlement_date, "2M", 0.018335, dcType)
depo3 = IborDeposit(settlement_date, "3M", 0.018988, dcType)
depo4 = IborDeposit(settlement_date, "6M", 0.018911, dcType)
depo5 = IborDeposit(settlement_date, "12M", 0.019093, dcType)
depos = [depo1,depo2,depo3,depo4,depo5]

swapType = SwapTypes.PAY
dcType = DayCountTypes.THIRTY_E_360_ISDA
fixedFreq = FrequencyTypes.SEMI_ANNUAL
swap1 = IborSwap(settlement_date,"2Y",swapType,0.015630,fixedFreq,dcType)
swap2 = IborSwap(settlement_date,"3Y",swapType,0.015140,fixedFreq,dcType)
swap3 = IborSwap(settlement_date,"4Y",swapType,0.015065,fixedFreq,dcType)
swap4 = IborSwap(settlement_date,"5Y",swapType,0.015140,fixedFreq,dcType)
swap5 = IborSwap(settlement_date,"6Y",swapType,0.015270,fixedFreq,dcType)
swap6 = IborSwap(settlement_date,"7Y",swapType,0.015470,fixedFreq,dcType)
swap7 = IborSwap(settlement_date,"8Y",swapType,0.015720,fixedFreq,dcType)
swap8 = IborSwap(settlement_date,"9Y",swapType,0.016000,fixedFreq,dcType)
swap9 = IborSwap(settlement_date,"10Y",swapType,0.016285,fixedFreq,dcType)
swap10 = IborSwap(settlement_date,"12Y",swapType,0.01670,fixedFreq,dcType)
swaps = [swap1,swap2,swap3,swap4,swap5,swap6,swap7,swap8,swap9,swap10]

libor_curve = IborSingleCurve(valuation_date, depos, [], swaps)

If we check IborSingleCurve we will see it has no alternative implementation of df.

I believe the previous issue I raised questioning the mismatch against QuantLib implementation in FINIBORSINGLECURVE_ReplicatingQuantlibExample.ipynb is related to this issue. In this notebook, curves are constructed as IborSingeCurve and then were consumed in the valuation of the floating leg. Index curve are used correctly, as you have checked, but the problem is on discount curve. as I see we use a very plain dfValue = discount_curve.df(valuation_date) in the value function.

from financepy.

Agree with @YimingZhang07 here and I do think this is an issue @domokane .

The same issue, I believe, is indirectly referenced here and was of course discussed here. While I don't think there are any methodological issues with the change to floating leg valuation - indeed the added flexibility for distinct conventions is probably a good thing - I believe the change to the DiscountCurve.df() method default parameter values could be problematic more broadly. Any reference to a DiscountCurve.df() (or inherited class Curve - so all of the swap curve objects that are calibrated with their embedded methods) that expects (but does not explicitly specify) a convention different from ACT_ACT_ISDA will experience a change in behavior from this.

As the discount curve's day count attribute is set in swap curve calibration as part of input validation (e.g. here and here), and the discount curve sets its own default value on direct instantiation, I believe a better default parameter value in DiscountCurve.df() would be simply self._dc_type.

from financepy.