Repository navigation
Inconsistency in Day Count in Index Curve? #191
Description
In swap_float_leg.py, we have the following logic to compute the forward rate for reference index.
dfStart = index_curve.df(startAccruedDt)
dfEnd = index_curve.df(endAccruedDt)
fwd_rate = (dfStart / dfEnd - 1.0) / index_alphaindex_alpha is a result of year fraction using a day counter initialized by the index day count type we specified. (for example, this is Thirty E 360 when constructing a IBOR curve)
(index_alpha, num, _) = index_day_counter.year_frac(startAccruedDt,
endAccruedDt)However, dfStart and dfEnd, though using the same index curve, always discount by ACT_ACT_ISDA. This is because we didn't specify the day count type in its second argument.
def df(self,
dt: (list, Date),
day_count=DayCountTypes.ACT_ACT_ISDA):I am unsure if this is a convention - but it seems odd to me as we are using two different day count types on a single curve for time fraction and discounting factors.
Just want to point out before I forget the details, take the time for this.
Thanks,
Activity
nashquant commentedon Jul 30, 2023
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:
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
YimingZhang07 commentedon Aug 1, 2023
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
IborSingleCurveclass 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,FINCDS_ValuingCDSCompareToMarkit.ipynbFINIBORSINGLECURVE_BuildingASimpleIborCurve.ipynbWith typical usage like
If we check
IborSingleCurvewe will see it has no alternative implementation ofdf.I believe the previous issue I raised questioning the mismatch against QuantLib implementation in
FINIBORSINGLECURVE_ReplicatingQuantlibExample.ipynbis related to this issue. In this notebook, curves are constructed asIborSingeCurveand 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 plaindfValue = discount_curve.df(valuation_date)in thevaluefunction.gulls-on-parade commentedon Dec 3, 2023
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.
domokane commentedon Sep 19, 2026
Hi - I have been away. Can you let me know if this is still an issue.
Merge pull request #402 from AIM-IT4/fix/swap-index-daycount-191
huuan26 commentedon Oct 19, 2026
Hi @domokane,
To summarize the current status of this issue:
p.array(dt) producing an object array of Date instances instead of floats.
I have submitted PR #408 with a clean fix that:
fix(curves): align CDSCurve df and survival_prob vectorization and da…
Merge pull request #408 from huuan26/fix/curve-day-count-inconsistenc…