updated numeraire dates algorithm

[lePidduN7]

Hi everyone! I removed the approximation of the swap length from the algorithm used to add calibration points at known numeraire dates.

This should solve the runtime error I reported in the newsletter. I run the tests and Gaussian1dModels example from @pcaspers and it's working fine.

[boring-cyborg]

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

[CLAassistant]

All committers have signed the CLA.

[pcaspers]

@lePidduN7 thank you! This works and produces the following calibration points (I produced this output with std::cout << markov->modelOutputs() << std::endl;)

expiry;tenor;atm;annuity;digitalAdj;ytsAdj;marketzerorate;modelzerorate;diff(bp)
May 30th, 2025;5Y;0.02020475051509805;4.594843027316506;1;1;0.02000000000000001;0.02000002915802777;-0.0002915802775269039
June 3rd, 2026;4Y;0.02020459939176046;3.635164181093882;1;1;0.02000000000000003;0.02000002713878599;-0.0002713878596155572
June 3rd, 2027;3Y;0.02020512172123216;2.705090592353351;1;1;0.02000000000000001;0.0200000358473677;-0.000358473676853599
June 5th, 2028;2Y;0.02020472577400515;1.781687833812943;1;1;0.02000000000000001;0.02000001905044068;-0.000190504406763492
June 4th, 2029;1Y;0.02020528167025603;0.8842460117967191;1;1;0.01999999999999998;0.02000001997152971;-0.0001997152972860183
June 6th, 2030;1Y;0.0202064080421399;0.8710245076214637;1;1;0.02000000000000001;0.02000000750751861;-7.507518596377993e-05

I think the strategy of the current algorithm is a bit different. I would expect it to produce this calibration instrument set

expiry;tenor;atm;annuity;digitalAdj;ytsAdj;marketzerorate;modelzerorate;diff(bp)
May 30th, 2025;5Y;0.02020475051509805;4.594843027316506;1;1;0.02000000000000001;0.02000000714455062;-7.144550607379729e-05
June 3rd, 2026;12M;0.02020640804213989;0.9448285166153381;1;1;0.02000000000000003;0.02000004548668859;-0.0004548668855464122
June 3rd, 2027;12M;0.02020697125942437;0.9283199762901825;1;1;0.02000000000000001;0.02000002963706916;-0.0002963706914951847
June 5th, 2028;12M;0.02020528167025564;0.9023094570834171;1;1;0.02000000000000001;0.02000001804415405;-0.0001804415403899862
June 4th, 2029;12M;0.02020528167025603;0.8842460117967191;1;1;0.01999999999999998;0.0200000084736192;-8.473619212551187e-05

However it adds a 13M swaption which is one month too long. This causes an infinite loop adding 13M swaptions until the max allowed date is reached. I'll open another PR with my attempt to fix this. Let's compare the two PRs then and discuss which we want to pick?

[lePidduN7]

@pcaspers absolutely, thank you for reviewing it!

Just for my understanding: the final set of points to be added is the set of one-period swaptions spanning the coupon payments of the original calibration instruments right?

[pcaspers]

Yeah so the original idea was to add a swaption spanning the period until the date on which the numeraire is known, or a little bit over if necessary to get a whole multiple months for the underlying swap length.

But it's only one way of doing it.

[lePidduN7]

I'm closing this pull request, I see #1772 already produces more stable outputs and doesn't fail the unit-tests. I'll see if I can find other cases that generates errors.

Thanks again for reviewing this!