Bad interpolation ql.ZeroCurve

[marekkolman]

There seems to be a wrong interpolation in ql.ZeroCurve, returning zeroRate = 0.0 instead of a correct value.

I define a curve that has two edge points:

crv = ql.ZeroCurve([ql.Date(30, 8, 2023), ql.Date(31, 12, 2199)], 
                                 [0.02, 0.02], 
                                 ql.SimpleDayCounter(), 
                                 ql.TARGET())

If I retrieve rate for 2023-08-31 I get rate = 0.0, which is wrong:

# returns 0.0 instead of 0.02
crv.zeroRate(ql.Date(31, 8, 2023), ql.SimpleDayCounter(), ql.Continuous).rate() 

If I do

# returns correctly 0.02
crv.zeroRate(ql.Date(30, 8, 2023), ql.SimpleDayCounter(), ql.Continuous).rate() 

or

# returns correctly 0.02
crv.zeroRate(ql.Date(1, 9, 2023), ql.SimpleDayCounter(), ql.Continuous).rate()

I get 0.02. Not clear where the singularity at ql.Date(31, 8, 2023) comes from.

[boring-cyborg]

Thanks for posting! It might take a while before we look at your issue, so don't worry if there seems to be no feedback. We'll get to it.

[lballabio]

I haven't looked closely into the calculation to see what happens, but after experimenting a bit it looks like the problem is SimpleDayCounter. It was added as a convenience for a few examples, but honestly I wouldn't use it for any real work. It should probably be deprecated.

Using act/365 or act/360 as day-count convention works as expected.

[marekkolman]

The same issue is e.g. with
ql.Thirty360(ql.Thirty360.BondBasis).
So seems to be more than just the SimpleDayCounter

[lballabio]

Ok, found the issue—for a number of reasons (possibly different compounding etc), the zero rate is not returned directly from the interpolation but passes through a few conversions. The calculations don't work correctly for t=0, so there is a special case in the code for that. However, the check to trigger the special case is not for t==0 but for d == referenceDate. In this case, August 31 is not the reference date (August 30) so the code goes into the general case, but unfortunately t ==0 (because we're using 30/360) and this causes the calculations to fail. August 30 works because it goes into the special case, and September 1st works because t != 0.

I'll change the check so that it detects this case.

[lballabio]

Moving the issue to the main repo because the problem is in the underlying C++ code.

[lballabio]

Fixed by #1798, it will be in version 1.32