quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] Solved >> Asset swap calculation in QL-Python

[<for...@ya...>]

* { font-size: 13px; font-family: 'MS Pゴシック', sans-serif;}p, ul, ol, blockquote { margin: 0;}a { color: #0064c8; text-decoration: none;}a:hover { color: #0057af; text-decoration: underline;}a:active { color: #004c98;}
Hi Ben,




I agreed and compared their cashflows of float leg and found the differece. 

My QuantLib code starts at the settlement date of the bond, whereas BBG does at the accrual start date.




Thank you for your suggestion, Kenji




----- Original Message -----




From: "Ben Watson" <ben...@ma...>

To: "me" <for...@ya...>

Cc: "QuantLib users" <Qua...@li...>

Date: 2025/03/27 木 15:36

Subject: Re: [Quantlib-users] Asset swap calculation in QL-Python







I am not 100% sure what quantlib is doing here. I bespoked asset swap pricing using swap. 




But BBG asw calcs fixes the first coupon based on historical index (euribor fixing). It also includes the accrual on the fixed leg. This ineffect makes asw calculations a dirty price calculation. In BBG on the ASW screen, you can push the pricing to SWPM and you can see the accrual numbers on that screen. 




I hope that helps. 




Ben




On Wed, 26 Mar 2025, 10:36 pm forward_rate--- via QuantLib-users, <qua...@li...> wrote:

Hi All,




I calculated bond yield, I-spread, Z-spread, and ASW spread for IBM 1.25, 01/29/27 (ISIN XS1945110606) in the attached Jupyter notebook and compared them with Bloomberg. The calculated values for yield, I-spread, and Z-spread almost coincided with Bloomberg's. (attached BBG's screens)




Could someone please suggest where I might be going wrong with the ASW calculation? (My calculated ASW is 40.95bp, while Bloomberg's is 35.0bp.)




Thanks,

Kenji

_______________________________________________

 QuantLib-users mailing list

 Qua...@li...

 https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Asset swap calculation in QL-Python

[Ben W. <ben...@ma...>]

I am not 100% sure what quantlib is doing here. I bespoked asset swap
pricing using swap.

But BBG asw calcs fixes the first coupon based on historical index (euribor
fixing). It also includes the accrual on the fixed leg. This ineffect makes
asw calculations a dirty price calculation. In BBG on the ASW screen, you
can push the pricing to SWPM and you can see the accrual numbers on that
screen.

I hope that helps.

Ben

On Wed, 26 Mar 2025, 10:36 pm forward_rate--- via QuantLib-users, <
qua...@li...> wrote:

> Hi All,
>
>
> I calculated bond yield, I-spread, Z-spread, and ASW spread for IBM 1.25,
> 01/29/27 (ISIN XS1945110606) in the attached Jupyter notebook and compared
> them with Bloomberg. The calculated values for yield, I-spread, and
> Z-spread almost coincided with Bloomberg's. (attached BBG's screens)
>
>
> Could someone please suggest where I might be going wrong with the ASW
> calculation? (My calculated ASW is 40.95bp, while Bloomberg's is 35.0bp.)
>
>
> Thanks,
>
> Kenji
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Asset swap calculation in QL-Python

[<for...@ya...>]

* { font-size: 13px; font-family: 'MS Pゴシック', sans-serif;}p, ul, ol, blockquote { margin: 0;}a { color: #0064c8; text-decoration: none;}a:hover { color: #0057af; text-decoration: underline;}a:active { color: #004c98;}
Hi All,




I calculated bond yield, I-spread, Z-spread, and ASW spread for IBM 1.25, 01/29/27 (ISIN XS1945110606) in the attached Jupyter notebook and compared them with Bloomberg. The calculated values for yield, I-spread, and Z-spread almost coincided with Bloomberg's. (attached BBG's screens) 




Could someone please suggest where I might be going wrong with the ASW calculation? (My calculated ASW is 40.95bp, while Bloomberg's is 35.0bp.)




Thanks,

Kenji

[Quantlib-users] Swap Rate Helpers from Dates

[Martin A. <mau...@pe...>]

Hi All,

I am trying to use the new ql.SwapRateHelper.forDates() method.

However, it is not clear to me how it treats the dates for the rate setting
dates. Using the same maturity dates and conventions, I get additional rate
setting dates when using the forDates() method compared to using the
standard method with a tenor. The code snippet below illustrates the case.
Is this behaviour intended?

Thanks,
Martin

Code Snippet:
ql.Settings.instance().evaluationDate = ql.DateParser.parseISO("2024-02-29")

helpers = [
{
"name": "forDates SwapRateHelper",
"swap": ql.SwapRateHelper.forDates(
ql.QuoteHandle(ql.SimpleQuote(2.0 / 100)),
ql.DateParser.parseISO("2024-03-04"),
ql.DateParser.parseISO("2028-03-06"),
ql.TARGET(),
ql.Annual,
ql.ModifiedFollowing,
ql.Thirty360(ql.Thirty360.European),
ql.Euribor6M(),
),
}
]
helpers.append(
{
"name": "forTenor SwapRateHelper",
"swap": ql.SwapRateHelper(
ql.QuoteHandle(ql.SimpleQuote(2.0 / 100)),
ql.Period("4Y"),
ql.TARGET(),
ql.Annual,
ql.ModifiedFollowing,
ql.Thirty360(ql.Thirty360.European),
ql.Euribor6M(),
),
}
)

for helper in helpers:

h = helper["swap"]
s = h.swap()
fixed_leg = s.fixedLeg()
floating_leg = s.floatingLeg()

print(f"\n\n{helper['name']}")

print(f"Start Date: {h.earliestDate()}")
print(f"End Date: {h.maturityDate()}")

print(f"Fixed Leg: ({len(s.fixedLeg())} Dates)")
for leg in fixed_leg:
print(leg.date())

print("------")

print(f"Floating Leg: ({len(s.floatingLeg())} Dates)")
for leg in floating_leg:
print(leg.date())

*Output:*

*forDates SwapRateHelper* Start Date: March 4th, 2024 End Date: March 6th,
2028 Fixed Leg: (5 Dates) March 6th, 2024 March 6th, 2025 March 6th, 2026 March
8th, 2027 March 6th, 2028 ------ Floating Leg: (9 Dates) March 6th,
2024 September
6th, 2024 March 6th, 2025 September 8th, 2025 March 6th, 2026 September
7th, 2026 March 8th, 2027 September 6th, 2027 March 6th, 2028 *forTenor
SwapRateHelper* Start Date: March 4th, 2024 End Date: March 6th, 2028 Fixed
Leg: (4 Dates) March 4th, 2025 March 4th, 2026 March 4th, 2027 March 6th,
2028 ------ Floating Leg: (8 Dates) September 4th, 2024 March 4th,
2025 September
4th, 2025 March 4th, 2026 September 4th, 2026 March 4th, 2027 September
6th, 2027 March 6th, 2028

-- 

*Martin Aussenhof*
*Head of Solutions*

*E: *ma...@pe...
*T:* +447407401595

*PeerNova, Inc.*       *web* <http://peernova.com/>   |   *x*
<http://x.com/peernovainc>   |   *li*
<https://www.linkedin.com/company/peernova>     |   *fb*
<https://www.facebook.com/peernova>

The information transmitted in this email is intended only for the person
or entity it addresses. This email may contain confidential or privileged
information. If you are not the intended recipient of this message, please
do not read, copy, use, or disclose this communication and notify the
sender immediately. Any review, transmission, dissemination, or use of this
information by a person or entity other than the intended recipient is
prohibited.

Learn more about our Cuneiform Platform <https://peernova.com/platform> →

Re: [Quantlib-users] [<<EXT>>] Re: Transition from version 1:30 to 1.37+

[Luigi B. <lui...@gm...>]

Hi Ioannis,
    no, the MC path generation doesn't include discrete dividends as of now.

Luigi


On Fri, Mar 7, 2025 at 10:07 PM Ioannis Rigopoulos <qua...@de...>
wrote:

> One question related to the dividend topic.
>
> Does anyone know if discrete dividends can be handled in MonteCarlo in
> QuantLib?
>
> I know continuous dividend yields do, but I could not find anything that
> supports discrete jumps in the equity price paths.
>
> Thanks
>
> Ioannis
>
> On 3/7/2025 6:51 PM, Martin Adamec via QuantLib-users wrote:
>
> Hi Luigi,
>
> Thank you for your response and useful hints. It it very helpful summary
> and it it matches our general understanding that we formed after checking
> of few previous posts in the mailing list as well as some other resources
> that we could find online.
>
> The only thing on which I couldn’t find more clarity is the way of
> “packaging” discrete dividends vs. dividend yield before sending it to
> either ql.AnalyticDividendEuropeanEngine or ql.FdBlackScholesVanillaEngine
> exercise engines. I noticed that some shifts in data preparation paradigm
> happened specifically in that area and that is actually the main reason why
> I sent this question to the mailing list. I know I should be more specific
> in my first email, but I hope I clarified my concern now.
>
> Please send me a few hints as how to proceed in either case when preparing
> dividend information to be passed to the exercise engine.
>
> Once more, thank you very much
>
> Martin
>
> Martin AdamecCTO, DataDock Solutionsdatadocksolutions.com
> 862-221-1246 | martin@datadocksolutions.com40 Wall St, FL 43 | New York, NY 10005 | USA <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>
>  On Mar 7, 2025 at 10:09 AM -0500, Luigi Ballabio
> <lui...@gm...> <lui...@gm...>, wrote:
>
> Hi Martin,
>      your excerpt seems to miss some possible combinations (European
> option with actual dividend data), or to allow some that wouldn't work
> correctly (DividendVanillaOption with BinomialVanillaEngine) but that might
> be because it's an excerpt, and you have other checks elsewhere.  Anyway,
> trying to summarize the current status:
>
> a) always use ql.VanillaOption(payoff, exercise), because
> ql.DividendVanillaOption has been absorbed into it;
> b) choose the engine depending on exercise and whether you have actual
> dividend data:
>     - for European options without dividend data, use
> ql.AnalyticEuropeanEngine(process);
>     - for European options with dividend data, use
> ql.AnalyticDividendEuropeanEngine(process, dividends);
>     - for American options without dividend data, use
> either ql.FdBlackScholesVanillaEngine(process)
> or ql.BinomialVanillaEngine(process, ...);
>     - for American options with dividend data, use
> ql.FdBlackScholesVanillaEngine(process, dividends).  The binomial engine
> doesn't support dividends.
>
> In short, if you have actual dividend data, pass them to an engine that
> can take care of them.
>
> Hope this helps,
>     Luigi
>
>
>
>
>
> On Tue, Mar 4, 2025 at 6:00 PM Martin Adamec via QuantLib-users <
> qua...@li...> wrote:
>
>> Hi quantlib-users,
>>
>> I am reaching out to ask you guys for some hints on proper transitioning
>> to the newly refactored classes and methods related to equity option
>> valuation calcs.
>>
>> We have in our code the older and now apparently outdated construct based
>> on previous organization of the code. It is semi-clear to us how to proceed
>> with the code available in version 1.37 (and most probably and hopefully up
>> for quite a long time).
>>
>> I attached an excerpt of the code that is dealing with the instantiation
>> and proper setup of the option object depending on the exercise style,
>> preselection of the engine, and finally the distinction between the
>> presence of discrete dividend data vs. dividend yield.
>>
>> My understanding is that the new code should be used in somehow simpler
>> fashion but cannot quit clearly figure out the proper way (and maybe order)
>> of setup steps to do to hit all of the input data variations we are
>> considering in our current code.
>>
>> Any hint or advice is going to be highly appreciated,
>>
>> Thank you
>>
>> Martin AdamecCTO, DataDock Solutionsdatadocksolutions.com
>> 862-221-1246 | martin@datadocksolutions.com40 Wall St, FL 43 | New York, NY 10005 | USA <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>>
>>  _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>
>
> _______________________________________________
> QuantLib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_536333718022247569_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: [Quantlib-users] [<<EXT>>] Re: Transition from version 1:30 to 1.37+

[Luigi B. <lui...@gm...>]

Hi Martin,
     where the old DividendVanillaOption class used to take a vector of
dates and the corresponding vector of dividend amounts, the engines now
take a list of dividend objects.  In Python, you'll have to go, for
instance, from the old code:

    option = ql.DividendVanillaOption(payoff, exercise, dates, dividends)
    option.setPricingEngine(ql.FdBlackScholesVanillaEngine(process))

to the new code:

    option = ql.DividendVanillaOption(payoff, exercise)
    dividend_list = [ql.FixedDividend(amount, d) for d, amount in
zip(dates, dividends)]
    option.setPricingEngine(ql.FdBlackScholesVanillaEngine(process,
dividend_list))

The same goes for the other engines.  In C++ there is a `DividendVector`
function that simplifies getting the list of dividends, but for some reason
it's not exported to Python; we should do that in a future release.  When
that happens, you'll be able to write
`ql.FdBlackScholesVanillaEngine(process, ql.DividendVector(dates,
dividends))`.

As before, the continuous dividend yield (if any) goes into the
Black-Scholes process; that part didn't change.

Luigi



On Fri, Mar 7, 2025 at 6:51 PM Martin Adamec <ma...@da...>
wrote:

> Hi Luigi,
>
> Thank you for your response and useful hints. It it very helpful summary
> and it it matches our general understanding that we formed after checking
> of few previous posts in the mailing list as well as some other resources
> that we could find online.
>
> The only thing on which I couldn’t find more clarity is the way of
> “packaging” discrete dividends vs. dividend yield before sending it to
> either ql.AnalyticDividendEuropeanEngine or ql.FdBlackScholesVanillaEngine
> exercise engines. I noticed that some shifts in data preparation paradigm
> happened specifically in that area and that is actually the main reason why
> I sent this question to the mailing list. I know I should be more specific
> in my first email, but I hope I clarified my concern now.
>
> Please send me a few hints as how to proceed in either case when preparing
> dividend information to be passed to the exercise engine.
>
> Once more, thank you very much
>
> Martin
>
>
> Martin Adamec
> CTO, DataDock Solutions
> datadocksolutions.com
>
>
> 862-221-1246 | ma...@da...
> 40 Wall St, FL 43 | New York, NY 10005 | USA <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>
>
>
> On Mar 7, 2025 at 10:09 AM -0500, Luigi Ballabio <lui...@gm...>,
> wrote:
>
> Hi Martin,
>      your excerpt seems to miss some possible combinations (European
> option with actual dividend data), or to allow some that wouldn't work
> correctly (DividendVanillaOption with BinomialVanillaEngine) but that might
> be because it's an excerpt, and you have other checks elsewhere.  Anyway,
> trying to summarize the current status:
>
> a) always use ql.VanillaOption(payoff, exercise), because
> ql.DividendVanillaOption has been absorbed into it;
> b) choose the engine depending on exercise and whether you have actual
> dividend data:
>     - for European options without dividend data, use
> ql.AnalyticEuropeanEngine(process);
>     - for European options with dividend data, use
> ql.AnalyticDividendEuropeanEngine(process, dividends);
>     - for American options without dividend data, use
> either ql.FdBlackScholesVanillaEngine(process)
> or ql.BinomialVanillaEngine(process, ...);
>     - for American options with dividend data, use
> ql.FdBlackScholesVanillaEngine(process, dividends).  The binomial engine
> doesn't support dividends.
>
> In short, if you have actual dividend data, pass them to an engine that
> can take care of them.
>
> Hope this helps,
>     Luigi
>
>
>
>
>
> On Tue, Mar 4, 2025 at 6:00 PM Martin Adamec via QuantLib-users <
> qua...@li...> wrote:
>
>> Hi quantlib-users,
>>
>> I am reaching out to ask you guys for some hints on proper transitioning
>> to the newly refactored classes and methods related to equity option
>> valuation calcs.
>>
>> We have in our code the older and now apparently outdated construct based
>> on previous organization of the code. It is semi-clear to us how to proceed
>> with the code available in version 1.37 (and most probably and hopefully up
>> for quite a long time).
>>
>> I attached an excerpt of the code that is dealing with the instantiation
>> and proper setup of the option object depending on the exercise style,
>> preselection of the engine, and finally the distinction between the
>> presence of discrete dividend data vs. dividend yield.
>>
>> My understanding is that the new code should be used in somehow simpler
>> fashion but cannot quit clearly figure out the proper way (and maybe order)
>> of setup steps to do to hit all of the input data variations we are
>> considering in our current code.
>>
>> Any hint or advice is going to be highly appreciated,
>>
>> Thank you
>>
>>
>> Martin Adamec
>> CTO, DataDock Solutions
>> datadocksolutions.com
>>
>>
>> 862-221-1246 | ma...@da...
>> 40 Wall St, FL 43 | New York, NY 10005 | USA <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>>
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Fwd: Seeking help with Quantlib Installation on Lubuntu 24.04 LTS

[Luigi B. <lui...@gm...>]

Hello Aniket,
    a few questions to try and diagnose the problem.

I'm assuming you followed the instructions at <
https://www.quantlib.org/install/linux.shtml> to install the C++ library,
right?  When you ran `sudo make install` at some point in those
instructions, did the command complete successfully?

If you didn't specify a different target directory, the installation should
have written, for instance, `ql/version.hpp` (a whole `ql` directory, as a
matter of fact) in `/usr/local/include/`.  You should also have a script
called `quantlib-config` in `/usr/local/bin/`.  Is this the case?  If you
try to run `quantlib-config` from a terminal, or if you run `which
quantlib-config`, do you find it?

If not, where did you install the library?

Later,
    Luigi

P.S. This said, if you don't want to modify the wrappers, getting a
precompiled wheel with `pip install QuantLib` is not a make-do solution,
it's the recommended one.




On Sat, Mar 8, 2025 at 9:18 AM Aniket Basu <ani...@gm...> wrote:

> Hello all,
>
> I am a newbie here. I tried compiling the wheel for QuantLib-Python on my
> machine under lubuntu 24.04 lts, but failed multiple times. Ultimately, I
> had to make do with a precompiled wheel. I am pasting below my conversation
> with Dr Luigi Ballabio, who advised me to post it to the group for common
> benefit. If anyone has any idea why this is not working, please advise.
>
> Thanks in advance,
>
> Cheers,
>
> Aniket
>
> ---------- Forwarded message ---------
> From: Aniket Basu <ani...@gm...>
> Date: Fri, 7 Mar 2025 at 00:08
> Subject: Re: Seeking help with Quantlib Installation on Lubuntu 24.04 LTS
> To: Luigi Ballabio <lui...@gm...>
>
>
> Ok, I will do that tomorrow morning. It's 12 midnight here and I am late
> for dinner.
>
> Somehow on my computer I am failing to build the wheel. I finally used the
> wheel from PyPI.
>
> Thanks.
>
> On Fri, 7 Mar 2025 at 00:05, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> May I ask you to post the question on the QuantLib mailing list, at <
>> qua...@li...>? This way it will be useful to
>> others, as well.
>>
>> Thanks,
>>      Luigi
>>
>> Il Gio 6 Mar 2025, 19:18 Aniket Basu <ani...@gm...> ha scritto:
>>
>>> Actually the compilation seems to fail at the line:
>>>
>>> #include <ql/version.hpp>
>>>
>>> I beg your pardon, should there be a space between #include and
>>> <ql/version.hpp> ?
>>>
>>> I can see no reason why the compiler/interpreter cannot locate
>>> ql/version.hpp when it is very much there in the system.
>>>
>>>
>>>
>>> On Thu, 6 Mar 2025 at 21:51, Luigi Ballabio <lui...@gm...>
>>> wrote:
>>>
>>>> I know (you did mention the Python instructions in your mail), but
>>>> building the Python version requires the C++ version to be built and
>>>> installed.  I think the instructions mention it.
>>>>
>>>> This said, if you don't mean to modify the C++ library or the wrappers,
>>>> you don't need to build the Python module (or the C++ one).  You can
>>>> install a precompiled wheel from PyPI; the page you linked has instructions
>>>> for this, as well.
>>>>
>>>> Hope this helps,
>>>>     Luigi
>>>>
>>>>
>>>> On Thu, Mar 6, 2025 at 5:16 PM Aniket Basu <ani...@gm...>
>>>> wrote:
>>>>
>>>>> Sorry, I should have been more specific:
>>>>>
>>>>> I meant the QuantLib-Python, not the C++ version.
>>>>>
>>>>> Sorry for bugging you.
>>>>>
>>>>> On Thu, 6 Mar 2025 at 21:32, Luigi Ballabio <lui...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>     please check that you followed the instructions at <
>>>>>> https://www.quantlib.org/install/linux.shtml> to build and also
>>>>>> install the library before trying to build the Python module.
>>>>>>
>>>>>> If the error still occurs, may I ask you to post the question on the
>>>>>> QuantLib mailing list, at <qua...@li...>?
>>>>>> This way it will be useful to others, as well.
>>>>>>
>>>>>> Thanks,
>>>>>>      Luigi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 6, 2025 at 4:42 PM Aniket Basu <ani...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Dear Dr Ballabio,
>>>>>>>
>>>>>>> While following the instructions here
>>>>>>>
>>>>>>> https://www.quantlib.org/install/linux-python.shtml
>>>>>>>
>>>>>>> once I run the command
>>>>>>>
>>>>>>> make
>>>>>>>
>>>>>>> under the Python directory, I get the following error messages:
>>>>>>>
>>>>>>> src/QuantLib/quantlib_wrap.cpp:5526:10: fatal error: ql/version.hpp:
>>>>>>> No such file or directory
>>>>>>>  5526 | #include <ql/version.hpp>
>>>>>>>       |          ^~~~~~~~~~~~~~~~
>>>>>>> compilation terminated.
>>>>>>> error: command '/usr/bin/g++' failed with exit code 1
>>>>>>>
>>>>>>> ERROR Backend subprocess exited when trying to invoke build_wheel
>>>>>>> make[1]: *** [Makefile:446: .build-stamp] Error 1
>>>>>>> make[1]: Leaving directory '/home/aniket/QuantLib-SWIG-1.36/Python'
>>>>>>> make: *** [Makefile:237: all] Error 2
>>>>>>>
>>>>>>> Please advise on how to proceed.
>>>>>>>
>>>>>>> Looking forward to hearing from you,
>>>>>>>
>>>>>>> Sincerely,
>>>>>>>
>>>>>>> Aniket Basu
>>>>>>> Assistant Professor
>>>>>>> Department of Physics
>>>>>>> Vidyasagar College
>>>>>>> Kolkata
>>>>>>>
>>>>>>> Email: ani...@gm...
>>>>>>>
>>>>>> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Intraday Feature Issue in QuantLib 1.38: Installed Headers Missing datetime.hpp

[Luigi B. <lui...@gm...>]

Hi, I answered in the issue you opened for the same problem (
https://github.com/lballabio/QuantLib/issues/2167).

Luigi

On Sat, Mar 8, 2025 at 11:01 AM Mellisa Kruger <igo...@gm...> wrote:

>
> I'm trying to build QuantLib with intraday support on Ubuntu (WSL), but
> after compiling and installing, I can't find the intraday datetime header
> (ql/time/datetime.hpp) and looks like it is not enabled.
>
> In the QuantLib source directory, I ran:
>
> ./configure CXXFLAGS="-DQL_USE_DATE_DATETIME -O3" --enable-intraday
> make -j$(nproc)
> sudo make install
>
> The build logs clearly show that the -DQL_USE_DATE_DATETIME flag is being
> passed during compile. For example, during the build I see a lot of lines
> like this:
>
> libtool: compile:  g++ -DHAVE_CONFIG_H -I../.. -I../.. -DQL_USE_DATE_DATETIME -O3 -std=c++17 -std=c++17 -MT payoffs.lo
> ...
>
> After running sudo make install, I ran:
>
> grep -R "QL_USE_DATE_DATETIME" .
>
> and I got the following :
>
> ./dev/QuantLib/m4/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME -O3 -std=c++17
> ./dev/QuantLib/test-suite/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME -O3 -std=c++17
> ./dev/QuantLib/Examples/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME -O3 -std=c++17
> ./dev/QuantLib/config.log:  $ ./configure 'CXXFLAGS=-DQL_USE_DATE_DATETIME -O3' --enable-intraday
> ./dev/QuantLib/config.log:configure:5339: g++ -c -DQL_USE_DATE_DATETIME -O3  conftest.cpp >&5
> ./dev/QuantLib/config.log:configure:5460: g++  -c -DQL_USE_DATE_DATETIME -O3  conftest.cpp >&5
>
> Despite this, after installation:
>
> When I run:
>
> grep QL_USE_DATE_DATETIME ~/dev/QuantLib/ql/config.hpp
>
> nothing gets printed. Also the intraday header file does not exist:
>
> ls /usr/local/include/ql/time/datetime.hpp
>
> returns:
>
> ls: cannot access '/usr/local/include/ql/time/datetime.hpp': No such file or directory
>
> Questions:
>
>    - Am I doing something wrong, or is there a specific version I need to
>    use? (I'm using QuantLib 1.38.)
>    - Why is the macro QL_USE_DATE_DATETIME not appearing in ql/config.hpp
>    even though the build logs show the flag is used?
>    - Are there additional configuration steps or known issues that could
>    cause the intraday support not to be installed properly?
>
> Any help you can offer would be greatly appreciated.
>
>
> StackOverflow Link
> <https://stackoverflow.com/questions/79494184/quantlib-1-38-build-problem-intraday-support-flag-not-reflected-in-config-hpp>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Intraday Feature Issue in QuantLib 1.38: Installed Headers Missing datetime.hpp

[Mellisa K. <igo...@gm...>]

I'm trying to build QuantLib with intraday support on Ubuntu (WSL), but
after compiling and installing, I can't find the intraday datetime header
(ql/time/datetime.hpp) and looks like it is not enabled.

In the QuantLib source directory, I ran:

./configure CXXFLAGS="-DQL_USE_DATE_DATETIME -O3" --enable-intraday
make -j$(nproc)
sudo make install

The build logs clearly show that the -DQL_USE_DATE_DATETIME flag is being
passed during compile. For example, during the build I see a lot of lines
like this:

libtool: compile:  g++ -DHAVE_CONFIG_H -I../.. -I../..
-DQL_USE_DATE_DATETIME -O3 -std=c++17 -std=c++17 -MT payoffs.lo
...

After running sudo make install, I ran:

grep -R "QL_USE_DATE_DATETIME" .

and I got the following :

./dev/QuantLib/m4/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME -O3 -std=c++17
./dev/QuantLib/test-suite/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME
-O3 -std=c++17
./dev/QuantLib/Examples/Makefile:CXXFLAGS = -DQL_USE_DATE_DATETIME -O3
-std=c++17
./dev/QuantLib/config.log:  $ ./configure
'CXXFLAGS=-DQL_USE_DATE_DATETIME -O3' --enable-intraday
./dev/QuantLib/config.log:configure:5339: g++ -c
-DQL_USE_DATE_DATETIME -O3  conftest.cpp >&5
./dev/QuantLib/config.log:configure:5460: g++  -c
-DQL_USE_DATE_DATETIME -O3  conftest.cpp >&5

Despite this, after installation:

When I run:

grep QL_USE_DATE_DATETIME ~/dev/QuantLib/ql/config.hpp

nothing gets printed. Also the intraday header file does not exist:

ls /usr/local/include/ql/time/datetime.hpp

returns:

ls: cannot access '/usr/local/include/ql/time/datetime.hpp': No such
file or directory

Questions:

   - Am I doing something wrong, or is there a specific version I need to
   use? (I'm using QuantLib 1.38.)
   - Why is the macro QL_USE_DATE_DATETIME not appearing in ql/config.hpp
   even though the build logs show the flag is used?
   - Are there additional configuration steps or known issues that could
   cause the intraday support not to be installed properly?

Any help you can offer would be greatly appreciated.


StackOverflow Link
<https://stackoverflow.com/questions/79494184/quantlib-1-38-build-problem-intraday-support-flag-not-reflected-in-config-hpp>

[Quantlib-users] Fwd: Seeking help with Quantlib Installation on Lubuntu 24.04 LTS

[Aniket B. <ani...@gm...>]

Hello all,

I am a newbie here. I tried compiling the wheel for QuantLib-Python on my
machine under lubuntu 24.04 lts, but failed multiple times. Ultimately, I
had to make do with a precompiled wheel. I am pasting below my conversation
with Dr Luigi Ballabio, who advised me to post it to the group for common
benefit. If anyone has any idea why this is not working, please advise.

Thanks in advance,

Cheers,

Aniket

---------- Forwarded message ---------
From: Aniket Basu <ani...@gm...>
Date: Fri, 7 Mar 2025 at 00:08
Subject: Re: Seeking help with Quantlib Installation on Lubuntu 24.04 LTS
To: Luigi Ballabio <lui...@gm...>


Ok, I will do that tomorrow morning. It's 12 midnight here and I am late
for dinner.

Somehow on my computer I am failing to build the wheel. I finally used the
wheel from PyPI.

Thanks.

On Fri, 7 Mar 2025 at 00:05, Luigi Ballabio <lui...@gm...>
wrote:

> May I ask you to post the question on the QuantLib mailing list, at <
> qua...@li...>? This way it will be useful to
> others, as well.
>
> Thanks,
>      Luigi
>
> Il Gio 6 Mar 2025, 19:18 Aniket Basu <ani...@gm...> ha scritto:
>
>> Actually the compilation seems to fail at the line:
>>
>> #include <ql/version.hpp>
>>
>> I beg your pardon, should there be a space between #include and
>> <ql/version.hpp> ?
>>
>> I can see no reason why the compiler/interpreter cannot locate
>> ql/version.hpp when it is very much there in the system.
>>
>>
>>
>> On Thu, 6 Mar 2025 at 21:51, Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> I know (you did mention the Python instructions in your mail), but
>>> building the Python version requires the C++ version to be built and
>>> installed.  I think the instructions mention it.
>>>
>>> This said, if you don't mean to modify the C++ library or the wrappers,
>>> you don't need to build the Python module (or the C++ one).  You can
>>> install a precompiled wheel from PyPI; the page you linked has instructions
>>> for this, as well.
>>>
>>> Hope this helps,
>>>     Luigi
>>>
>>>
>>> On Thu, Mar 6, 2025 at 5:16 PM Aniket Basu <ani...@gm...>
>>> wrote:
>>>
>>>> Sorry, I should have been more specific:
>>>>
>>>> I meant the QuantLib-Python, not the C++ version.
>>>>
>>>> Sorry for bugging you.
>>>>
>>>> On Thu, 6 Mar 2025 at 21:32, Luigi Ballabio <lui...@gm...>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>     please check that you followed the instructions at <
>>>>> https://www.quantlib.org/install/linux.shtml> to build and also
>>>>> install the library before trying to build the Python module.
>>>>>
>>>>> If the error still occurs, may I ask you to post the question on the
>>>>> QuantLib mailing list, at <qua...@li...>?
>>>>> This way it will be useful to others, as well.
>>>>>
>>>>> Thanks,
>>>>>      Luigi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 6, 2025 at 4:42 PM Aniket Basu <ani...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Dear Dr Ballabio,
>>>>>>
>>>>>> While following the instructions here
>>>>>>
>>>>>> https://www.quantlib.org/install/linux-python.shtml
>>>>>>
>>>>>> once I run the command
>>>>>>
>>>>>> make
>>>>>>
>>>>>> under the Python directory, I get the following error messages:
>>>>>>
>>>>>> src/QuantLib/quantlib_wrap.cpp:5526:10: fatal error: ql/version.hpp:
>>>>>> No such file or directory
>>>>>>  5526 | #include <ql/version.hpp>
>>>>>>       |          ^~~~~~~~~~~~~~~~
>>>>>> compilation terminated.
>>>>>> error: command '/usr/bin/g++' failed with exit code 1
>>>>>>
>>>>>> ERROR Backend subprocess exited when trying to invoke build_wheel
>>>>>> make[1]: *** [Makefile:446: .build-stamp] Error 1
>>>>>> make[1]: Leaving directory '/home/aniket/QuantLib-SWIG-1.36/Python'
>>>>>> make: *** [Makefile:237: all] Error 2
>>>>>>
>>>>>> Please advise on how to proceed.
>>>>>>
>>>>>> Looking forward to hearing from you,
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> Aniket Basu
>>>>>> Assistant Professor
>>>>>> Department of Physics
>>>>>> Vidyasagar College
>>>>>> Kolkata
>>>>>>
>>>>>> Email: ani...@gm...
>>>>>>
>>>>>

Re: [Quantlib-users] [<<EXT>>] Re: Transition from version 1:30 to 1.37+

[Ioannis R. <qua...@de...>]

One question related to the dividend topic.

Does anyone know if discrete dividends can be handled in MonteCarlo in 
QuantLib?

I know continuous dividend yields do, but I could not find anything that 
supports discrete jumps in the equity price paths.

Thanks

Ioannis

On 3/7/2025 6:51 PM, Martin Adamec via QuantLib-users wrote:
> Hi Luigi,
>
> Thank you for your response and useful hints. It it very helpful 
> summary and it it matches our general understanding that we formed 
> after checking of few previous posts in the mailing list as well as 
> some other resources that we could find online.
>
> The only thing on which I couldn’t find more clarity is the way of 
> “packaging” discrete dividends vs. dividend yield before sending it to 
> either ql.AnalyticDividendEuropeanEngine or 
> ql.FdBlackScholesVanillaEngine exercise engines. I noticed that some 
> shifts in data preparation paradigm happened specifically in that area 
> and that is actually the main reason why I sent this question to the 
> mailing list. I know I should be more specific in my first email, but 
> I hope I clarified my concern now.
>
> Please send me a few hints as how to proceed in either case when 
> preparing dividend information to be passed to the exercise engine.
>
> Once more, thank you very much
>
> Martin
>
> Martin Adamec CTO, DataDock Solutions datadocksolutions.com 
> <https://datadocksolutions.com/> 
> 862-221-1246|ma...@da... 40 Wall St, FL 43 | New 
> York, NY 10005 | USA 
> <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA> 
>
> On Mar 7, 2025 at 10:09 AM -0500, Luigi Ballabio 
> <lui...@gm...>, wrote:
>> Hi Martin,
>>      your excerpt seems to miss some possible combinations (European 
>> option with actual dividend data), or to allow some that wouldn't 
>> work correctly (DividendVanillaOption with BinomialVanillaEngine) but 
>> that might be because it's an excerpt, and you have other checks 
>> elsewhere.  Anyway, trying to summarize the current status:
>>
>> a) always use ql.VanillaOption(payoff, exercise), because 
>> ql.DividendVanillaOption has been absorbed into it;
>> b) choose the engine depending on exercise and whether you have 
>> actual dividend data:
>>     - for European options without dividend data, use 
>> ql.AnalyticEuropeanEngine(process);
>>     - for European options with dividend data, use 
>> ql.AnalyticDividendEuropeanEngine(process, dividends);
>>     - for American options without dividend data, use 
>> either ql.FdBlackScholesVanillaEngine(process) 
>> or ql.BinomialVanillaEngine(process, ...);
>>     - for American options with dividend data, use 
>> ql.FdBlackScholesVanillaEngine(process, dividends).  The binomial 
>> engine doesn't support dividends.
>>
>> In short, if you have actual dividend data, pass them to an engine 
>> that can take care of them.
>>
>> Hope this helps,
>>     Luigi
>>
>>
>>
>>
>>
>> On Tue, Mar 4, 2025 at 6:00 PM Martin Adamec via QuantLib-users 
>> <qua...@li...> wrote:
>>
>>     Hi quantlib-users,
>>
>>     I am reaching out to ask you guys for some hints on proper
>>     transitioning to the newly refactored classes and methods related
>>     to equity option valuation calcs.
>>
>>     We have in our code the older and now apparently outdated
>>     construct based on previous organization of the code. It is
>>     semi-clear to us how to proceed with the code available in
>>     version 1.37 (and most probably and hopefully up for quite a long
>>     time).
>>
>>     I attached an excerpt of the code that is dealing with the
>>     instantiation and proper setup of the option object depending on
>>     the exercise style, preselection of the engine, and finally the
>>     distinction between the presence of discrete dividend data vs.
>>     dividend yield.
>>
>>     My understanding is that the new code should be used in somehow
>>     simpler fashion but cannot quit clearly figure out the proper way
>>     (and maybe order) of setup steps to do to hit all of the input
>>     data variations we are considering in our current code.
>>
>>     Any hint or advice is going to be highly appreciated,
>>
>>     Thank you
>>
>>     Martin Adamec CTO, DataDock Solutions datadocksolutions.com
>>     <https://datadocksolutions.com/>
>>     862-221-1246|ma...@da... 40 Wall St, FL 43 | New
>>     York, NY 10005 | USA
>>     <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>>
>>
>>     _______________________________________________
>>     QuantLib-users mailing list
>>     Qua...@li...
>>     https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: [Quantlib-users] [<<EXT>>] Re: Transition from version 1:30 to 1.37+

[Martin A. <ma...@da...>]

Hi Luigi,

Thank you for your response and useful hints. It it very helpful summary and it it matches our general understanding that we formed after checking of few previous posts in the mailing list as well as some other resources that we could find online.

The only thing on which I couldn’t find more clarity is the way of “packaging” discrete dividends vs. dividend yield before sending it to either ql.AnalyticDividendEuropeanEngine or ql.FdBlackScholesVanillaEngine exercise engines. I noticed that some shifts in data preparation paradigm happened specifically in that area and that is actually the main reason why I sent this question to the mailing list. I know I should be more specific in my first email, but I hope I clarified my concern now.

Please send me a few hints as how to proceed in either case when preparing dividend information to be passed to the exercise engine.

Once more, thank you very much

Martin


Martin Adamec
CTO, DataDock Solutions
datadocksolutions.com


862-221-1246 | ma...@da...
40 Wall St, FL 43 | New York, NY 10005 | USA



On Mar 7, 2025 at 10:09 AM -0500, Luigi Ballabio <lui...@gm...>, wrote:
> Hi Martin,
>      your excerpt seems to miss some possible combinations (European option with actual dividend data), or to allow some that wouldn't work correctly (DividendVanillaOption with BinomialVanillaEngine) but that might be because it's an excerpt, and you have other checks elsewhere.  Anyway, trying to summarize the current status:
>
> a) always use ql.VanillaOption(payoff, exercise), because ql.DividendVanillaOption has been absorbed into it;
> b) choose the engine depending on exercise and whether you have actual dividend data:
>     - for European options without dividend data, use ql.AnalyticEuropeanEngine(process);
>     - for European options with dividend data, use ql.AnalyticDividendEuropeanEngine(process, dividends);
>     - for American options without dividend data, use either ql.FdBlackScholesVanillaEngine(process) or ql.BinomialVanillaEngine(process, ...);
>     - for American options with dividend data, use ql.FdBlackScholesVanillaEngine(process, dividends).  The binomial engine doesn't support dividends.
>
> In short, if you have actual dividend data, pass them to an engine that can take care of them.
>
> Hope this helps,
>     Luigi
>
>
>
>
>
> On Tue, Mar 4, 2025 at 6:00 PM Martin Adamec via QuantLib-users <qua...@li...> wrote:
> > Hi quantlib-users,
> >
> > I am reaching out to ask you guys for some hints on proper transitioning to the newly refactored classes and methods related to equity option valuation calcs.
> >
> > We have in our code the older and now apparently outdated construct based on previous organization of the code. It is semi-clear to us how to proceed with the code available in version 1.37 (and most probably and hopefully up for quite a long time).
> >
> > I attached an excerpt of the code that is dealing with the instantiation and proper setup of the option object depending on the exercise style, preselection of the engine, and finally the distinction between the presence of discrete dividend data vs. dividend yield.
> >
> > My understanding is that the new code should be used in somehow simpler fashion but cannot quit clearly figure out the proper way (and maybe order) of setup steps to do to hit all of the input data variations we are considering in our current code.
> >
> > Any hint or advice is going to be highly appreciated,
> >
> > Thank you
> >
> >
> > Martin Adamec
> > CTO, DataDock Solutions
> > datadocksolutions.com
> >
> >
> > 862-221-1246 | ma...@da...
> > 40 Wall St, FL 43 | New York, NY 10005 | USA
> >
> >
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Transition from version 1:30 to 1.37+

[Luigi B. <lui...@gm...>]

Hi Martin,
     your excerpt seems to miss some possible combinations (European option
with actual dividend data), or to allow some that wouldn't work correctly
(DividendVanillaOption with BinomialVanillaEngine) but that might be
because it's an excerpt, and you have other checks elsewhere.  Anyway,
trying to summarize the current status:

a) always use ql.VanillaOption(payoff, exercise), because
ql.DividendVanillaOption has been absorbed into it;
b) choose the engine depending on exercise and whether you have actual
dividend data:
    - for European options without dividend data, use
ql.AnalyticEuropeanEngine(process);
    - for European options with dividend data, use
ql.AnalyticDividendEuropeanEngine(process, dividends);
    - for American options without dividend data, use
either ql.FdBlackScholesVanillaEngine(process)
or ql.BinomialVanillaEngine(process, ...);
    - for American options with dividend data, use
ql.FdBlackScholesVanillaEngine(process, dividends).  The binomial engine
doesn't support dividends.

In short, if you have actual dividend data, pass them to an engine that can
take care of them.

Hope this helps,
    Luigi





On Tue, Mar 4, 2025 at 6:00 PM Martin Adamec via QuantLib-users <
qua...@li...> wrote:

> Hi quantlib-users,
>
> I am reaching out to ask you guys for some hints on proper transitioning
> to the newly refactored classes and methods related to equity option
> valuation calcs.
>
> We have in our code the older and now apparently outdated construct based
> on previous organization of the code. It is semi-clear to us how to proceed
> with the code available in version 1.37 (and most probably and hopefully up
> for quite a long time).
>
> I attached an excerpt of the code that is dealing with the instantiation
> and proper setup of the option object depending on the exercise style,
> preselection of the engine, and finally the distinction between the
> presence of discrete dividend data vs. dividend yield.
>
> My understanding is that the new code should be used in somehow simpler
> fashion but cannot quit clearly figure out the proper way (and maybe order)
> of setup steps to do to hit all of the input data variations we are
> considering in our current code.
>
> Any hint or advice is going to be highly appreciated,
>
> Thank you
>
>
> Martin Adamec
> CTO, DataDock Solutions
> datadocksolutions.com
>
>
> 862-221-1246 | ma...@da...
> 40 Wall St, FL 43 | New York, NY 10005 | USA <https://maps.google.com/?q=40%20Wall%20St,%20FL%2042%20%7C%20New%20York,%20NY%2010005%20%7C%20USA>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Transition from version 1:30 to 1.37+

[Martin A. <ma...@da...>]

Hi quantlib-users,

I am reaching out to ask you guys for some hints on proper transitioning to the newly refactored classes and methods related to equity option valuation calcs.

We have in our code the older and now apparently outdated construct based on previous organization of the code. It is semi-clear to us how to proceed with the code available in version 1.37 (and most probably and hopefully up for quite a long time).

I attached an excerpt of the code that is dealing with the instantiation and proper setup of the option object depending on the exercise style, preselection of the engine, and finally the distinction between the presence of discrete dividend data vs. dividend yield.

My understanding is that the new code should be used in somehow simpler fashion but cannot quit clearly figure out the proper way (and maybe order) of setup steps to do to hit all of the input data variations we are considering in our current code.

Any hint or advice is going to be highly appreciated,

Thank you


Martin Adamec
CTO, DataDock Solutions
datadocksolutions.com


862-221-1246 | ma...@da...
40 Wall St, FL 43 | New York, NY 10005 | USA

[Quantlib-users] Use CDS model to pricing options

[Rui W. <Rui...@gm...>]

Hi,

I am trying to use QuantLib to price CDX options but encountered some challenges. It seems that the QuantLib: CdsOption Class Reference<https://www.quantlib.org/reference/class_quant_lib_1_1_cds_option.html> CDS options class is incomplete and does not provide common metrics such as price, delta or gamma. I also noticed that a similar issue was raised before but remains unresolved.
Matching Bloomberg's CDSO using quantlib CdsOption * Issue #1341 * lballabio/QuantLib<https://github.com/lballabio/QuantLib/issues/1341>

To work around this, I looked into MATLAB's implementation, which constructs a forward CDS and then adds the FEP back to account for the additional protection between t and te. (te is the option expiry date)
Pricing a CDS Index Option<https://www.mathworks.com/help/fininst/pricing-a-cds-index-option.html>

I wrote the following code to replicate this approach, either by constructing a forward CDS directly or by creating a CDS for the period (t,te). In theory, either method should work if the underlying calculations aligned with the intended model.
However, I've found that both will have some discrepancies in the Adjusted Forward Spread and FwdRPV01 comparing with BLG or broker's data.

My questions are:

  *   Is there a better way to price CDS options from scratch using QuantLib?
  *   If not, following the current method, where might the discrepancies arise? I suspect the issue may be related to the FwdRPV01 calculation.

def calculate_fwd_spread_and_bpv(
    current_date: ql.Date,
    cds_maturity_date: ql.Date,
    option_expiry_date: ql.Date,
    spot_spread: float,
    running_spread: float,
    discount_curve: ql.YieldTermStructureHandle,
    notional: float = 1000000.0,
    recovery: float = 0.4,
    using_forward_cds: bool = False,
) -> dict:
    """Calculate forward spread, forward BPV, FEP, and adjusted forward spread.

    Args:
        current_date (ql.Date): Current date.
        cds_maturity_date (ql.Date): CDS maturity date.
        option_expiry_date (ql.Date): Option expiry date.
        spot_spread (float): Spot spread.
        running_spread (float): Running spread.
        discount_curve (ql.YieldTermStructureHandle): Discount curve.
        notional (float, optional): Notional amount. Default is 1000000.0.
        recovery (float, optional): Recovery rate. Default is 0.4.
        using_forward_cds (bool, optional): Whether to use forward CDS. Default is False.

    Returns:
        dict: A dictionary containing forward spread, forward BPV, FEP, and adjusted forward spread.
    """
    ql.Settings.instance().evaluationDate = current_date

    cds_maturity_schedule = create_cds_schedule(current_date, cds_maturity_date)
    options_maturity_schedule = create_cds_schedule(current_date, option_expiry_date)
    forward_cds_schedule = create_cds_schedule(option_expiry_date, cds_maturity_date)

    # Quoted trade to infer the hazard rate
    quoted_trade = ql.CreditDefaultSwap(
        ql.Protection.Seller, notional, 0, spot_spread, cds_maturity_schedule,
        ql.Following, ql.Actual360(), True
    )
    hazard_rate = quoted_trade.impliedHazardRate(
        0, discount_curve, ql.Actual365Fixed(), recovery, 1e-8, ql.CreditDefaultSwap.ISDA
    )

    # Create the CDS engine with the inferred hazard rate
    probability_curve = ql.FlatHazardRate(
        0, ql.WeekendsOnly(), ql.QuoteHandle(ql.SimpleQuote(hazard_rate)), ql.Actual365Fixed()
    )
    engine = ql.IsdaCdsEngine(
        ql.RelinkableDefaultProbabilityTermStructureHandle(probability_curve),
        recovery,
        discount_curve
    )
    if using_forward_cds:
        # determine which method to use
        forward_cds_trade = ql.CreditDefaultSwap(
            ql.Protection.Seller, notional, running_spread, forward_cds_schedule,
            ql.Following, ql.Actual360(), True
        )
        forward_cds_trade.setPricingEngine(engine)
        fwd_spread = forward_cds_trade.fairSpread()

        # Calculate Fwd BPV (present value of 1 bps spread)
        fwd_bpv = forward_cds_trade.couponLegBPS() / 1e2
    else:
        conventional_trade = ql.CreditDefaultSwap(
            ql.Protection.Seller, notional, running_spread, options_maturity_schedule,
            ql.Following, ql.Actual360(), True, True, current_date,
            ql.FaceValueClaim(), ql.Actual360(True), True
        )
        conventional_trade.setPricingEngine(engine)
        quoted_trade.setPricingEngine(engine)
        spread_t_te = conventional_trade.fairSpread()
        spread_t_tm = quoted_trade.fairSpread()

        # Calculate Fwd BPV (present value of 1 bps spread)
        rpv01_t_te = conventional_trade.couponLegBPS() / 1e2
        rpv01_t_tm = quoted_trade.couponLegBPS() / 1e2

        # calculate fwd spread
        fwd_bpv = rpv01_t_tm-rpv01_t_te
        fwd_spread = (spread_t_tm*rpv01_t_tm-spread_t_te*rpv01_t_te)/fwd_bpv

    # Calculate adjusted fwd spread
    discount_factor_te = discount_curve.discount(option_expiry_date)
    credit_curve_handle = ql.RelinkableDefaultProbabilityTermStructureHandle(probability_curve)
    survival_probability = credit_curve_handle.survivalProbability(option_expiry_date)
    fep = (1 - recovery) * discount_factor_te * (1 - survival_probability)
    fwd_spread_adj = fwd_spread + fep / fwd_bpv

    return {
        "fwd_spread": fwd_spread,
        "fwd_bpv": fwd_bpv,
        "fep": fep,
        "fwd_spread_adj": fwd_spread_adj
    }


Any guidance or insights would be greatly appreciated.
Rui

Re: [Quantlib-users] Unexpected rate given on last day of month when using OvernightIndexFutureRateHelper

[Luigi B. <lui...@gm...>]

Hello Emily,
    it's probably partly the setup and partly a lack of documentation.
There are a couple of issues at play.

The first: in the constructor of OvernightIndexFutureRateHelper, the start
date and maturity date are the start and end dates of the compounding
period of the underlying rate; for a futures on 1-month SOFR, the start and
maturity might be October 1st and November 1st, and the futures will
compound the SOFR fixings for all the days in between.  Even when your
evaluation date is, say, October 20th, the start date to pass will still be
October 1st because that's when the compounding starts and the rates from
October 1st and October 20th need to be included in the price.  In your
code, you're passing the evaluation date as start instead.  For your first
helper, this causes the start date to equal the maturity, which should
probably have raised an error.

Second thing: let's say you pass the correct start dates so the
compounding period of your first futures goes from, say, October 1st to
October 31st.  This means it will compound the overnight rate from Oct.1st
to Oct.2nd with the rate from 2nd to 3rd with all the rates in the middle
(glossing over the management of holidays and weekends) with the last rate,
which will be the one from the 30th to the 31st.   When the evaluation date
is October 31st, all these rates are in the past and the future is entirely
fixed.  This means that the curve does not participate in calculating its
price, and the helper is discarded from the bootstrapping process.  If the
fixing of October 31st is to be included, the maturity should be the
November 1st instead (which is what the SofrFutureRateHelper calculates
when passed October as the reference month).

Hope this helps,
    Luigi


On Tue, Jan 28, 2025 at 6:07 PM Emily Baker <Emi...@ch...>
wrote:

> Hello there,
>
>
>
> Curious if anyone has any thoughts on the below?
>
>
>
> Thanks again!
>
>
>
>
>
> *From: *Emily Baker <Emi...@ch...>
> *Date: *Friday, 17 January 2025 at 12:19
> *To: *qua...@li... <
> qua...@li...>
> *Subject: *Unexpected rate given on last day of month when using
> OvernightIndexFutureRateHelper
>
> Hello,
>
>
>
> I am trying to use QuantLib to build a yield curve using the
> OvernightIndexFutureRateHelper and FedFunds future prices, but am getting
> some unexpected results. When the evaluation date is the last day of the
> month (say, October 31, 2024) the future price for that month (in this
> case, October) does not affect the rate produced.
>
>
>
> Here is a minimal example in Python:
>
>
>
>
>
> reference_date = ql.Date(31,10,2024)
>
> im = ql.IndexManager.instance()
>
> day_counter = ql.Actual360()
>
> ql.Settings.instance().evaluationDate = reference_date
>
>
>
> ff_index = ql.FedFunds()
>
> im.clearHistory(ff_index.name())
>
>
>
> fixing_price = 0.05
>
> date = ql.Date(1,10,2024)
>
>
>
> while date < reference_date:
>
>     ff_index.addFixing(date, fixing_price)
>
>     date = ff_index.fixingCalendar().advance(date, 1, ql.Days)
>
>
>
> ff_helpers = []
>
>
>
> quoted_rates = [
>
>     (ql.QuoteHandle(ql.SimpleQuote(94)), ql.Date(31, 10, 2024)),
>
>     (ql.QuoteHandle(ql.SimpleQuote(95)), ql.Date(30, 11, 2024)),
>
> ]
>
>
>
> for rate, date in quoted_rates:
>
>     ff_helpers.append(ql.OvernightIndexFutureRateHelper(rate,
> reference_date, date, ff_index))
>
>
>
> ff_yield_curve = ql.PiecewiseFlatForward(reference_date, ff_helpers,
> day_counter, [], [])
>
>
>
> curve_dates = [min(ff_yield_curve.dates()) + x for x in
> range(max(ff_yield_curve.dates()) - min(ff_yield_curve.dates()))]
>
> zero_rates = [round(ff_yield_curve.zeroRate(d, day_counter,
> ql.Compounded).rate() * 100, 6) for d in curve_dates]
>
>
>
> pd.DataFrame(data={'Date': curve_dates, 'ZeroRate': zero_rates})
>
>
>
>
>
> No matter what price is set for the October 31, 2024 FedFunds future, the
> resulting rate does not change.
>
>
>
> Is this a bug, or is there a more recommended way of setting this up?
>
>
>
> Thanks,
> Emily
>
>
>
>
>
>
> This electronic mail message and any attached files contain information
> intended for the exclusive use of the individual or entity to whom it is
> addressed and may contain information that is proprietary, confidential
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information may be subject to legal
> restriction or sanction. Please notify the sender, by electronic mail or
> telephone, of any unintended recipients and delete the original message
> without making any copies. CTC London Limited is authorized and regulated
> by the Financial Conduct Authority.
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Unexpected rate given on last day of month when using OvernightIndexFutureRateHelper

[Emily B. <Emi...@ch...>]

Hello there,

Curious if anyone has any thoughts on the below?

Thanks again!


From: Emily Baker <Emi...@ch...>
Date: Friday, 17 January 2025 at 12:19
To: qua...@li... <qua...@li...>
Subject: Unexpected rate given on last day of month when using OvernightIndexFutureRateHelper
Hello,

I am trying to use QuantLib to build a yield curve using the OvernightIndexFutureRateHelper and FedFunds future prices, but am getting some unexpected results. When the evaluation date is the last day of the month (say, October 31, 2024) the future price for that month (in this case, October) does not affect the rate produced.

Here is a minimal example in Python:


reference_date = ql.Date(31,10,2024)
im = ql.IndexManager.instance()
day_counter = ql.Actual360()
ql.Settings.instance().evaluationDate = reference_date

ff_index = ql.FedFunds()
im.clearHistory(ff_index.name())

fixing_price = 0.05
date = ql.Date(1,10,2024)

while date < reference_date:
    ff_index.addFixing(date, fixing_price)
    date = ff_index.fixingCalendar().advance(date, 1, ql.Days)

ff_helpers = []

quoted_rates = [
    (ql.QuoteHandle(ql.SimpleQuote(94)), ql.Date(31, 10, 2024)),
    (ql.QuoteHandle(ql.SimpleQuote(95)), ql.Date(30, 11, 2024)),
]

for rate, date in quoted_rates:
    ff_helpers.append(ql.OvernightIndexFutureRateHelper(rate, reference_date, date, ff_index))

ff_yield_curve = ql.PiecewiseFlatForward(reference_date, ff_helpers, day_counter, [], [])

curve_dates = [min(ff_yield_curve.dates()) + x for x in range(max(ff_yield_curve.dates()) - min(ff_yield_curve.dates()))]
zero_rates = [round(ff_yield_curve.zeroRate(d, day_counter, ql.Compounded).rate() * 100, 6) for d in curve_dates]

pd.DataFrame(data={'Date': curve_dates, 'ZeroRate': zero_rates})


No matter what price is set for the October 31, 2024 FedFunds future, the resulting rate does not change.

Is this a bug, or is there a more recommended way of setting this up?

Thanks,
Emily






This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. CTC London Limited is authorized and regulated by the Financial Conduct Authority.

Re: [Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Luigi B. <lui...@gm...>]

For future reference: https://quant.stackexchange.com/questions/81706/


On Fri, Jan 17, 2025 at 8:25 PM Pranay Patil <
pra...@cr...> wrote:

> Thanks, I'll look into it.
>
> On Sat, 18 Jan 2025 at 12:51 AM, Trent Maetzold <tr...@ma...> wrote:
>
>> Someone might be able to give clarification on this, but the schedule
>> should determine the accrual schedule. You can have payments adjusted by
>> specifying following and eom = false on the actual instrument (so that the
>> cashflows get discounted correctly).
>>
>>
>> -------- Original Message --------
>>
>> On 1/17/25 11:18, Pranay Patil wrote:
>>
>> Thank you for the clarification.
>>
>> On Fri, 17 Jan 2025 at 8:21 PM, Roshan Yadav <er....@gm...>
>> wrote:
>>
>>> QuantLib applies the EOM (End of Month) rule, overriding the standard
>>> convention, which ensures that payment dates are always set to the end of
>>> the month.
>>>
>>> On Fri, 17 Jan, 2025, 7:22 pm Pranay Patil, <
>>> pra...@cr...> wrote:
>>>
>>>>   I am encountering an issue with the Schedule class in QuantLib while
>>>> trying to generate a payment schedule. Below is the scenario I am working
>>>> with:
>>>>
>>>> *Issue Date:* 1 January 2025
>>>> *Maturity Date:* 31 August 2025
>>>> *First Stub Date:* 31 January 2025
>>>> *Calendar Holiday:* 31 March 2025 (specified in the calendar)
>>>> *End-of-Month (EOM):* True
>>>>
>>>> this is my Code snippet
>>>> payment_schedule = ql.Schedule(
>>>>     issueDate,
>>>>     maturityDate,
>>>>     ql.Period(fromFrequency),
>>>>     calendar,
>>>>     ql.Following,
>>>>     ql.Unadjusted,
>>>>     dategeneration,
>>>>     eom,
>>>>     firststubdate
>>>> )
>>>>
>>>>   Even though I have specified ql.Following for the date adjustment
>>>> convention, the schedule generates a date of 30 March 2025 instead of the
>>>> expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month
>>>> (EOM) flag being set to True, I expected the date to roll forward to 1
>>>> April 2025.
>>>>
>>>> My evaluation is Schedule class is giving preference to the 'eom' flag,
>>>> not allowing me to choose next month's date according to the ql.Following
>>>> Can u help me with this how can i approach this  problem
>>>>
>>>> Thanks
>>>>
>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] QuantLib 1.37 released

[Luigi B. <lui...@gm...>]

QuantLib 1.37 is available for download at <
https://www.quantlib.org/download.shtml>; precompiled binaries are also
available from PyPI and NuGet for Python and C# respectively.

The list of changes for this release is at <
https://www.quantlib.org/reference/history.html>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>) or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

Re: [Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Trent M. <tr...@ma...>]

Someone might be able to give clarification on this, but the schedule should determine the accrual schedule. You can have payments adjusted by specifying following and eom = false on the actual instrument (so that the cashflows get discounted correctly).

-------- Original Message --------
On 1/17/25 11:18, Pranay Patil  wrote:

> Thank you for the clarification.
>
> On Fri, 17 Jan 2025 at 8:21 PM, Roshan Yadav <er....@gm...> wrote:
>
>> QuantLib applies the EOM (End of Month) rule, overriding the standard convention, which ensures that payment dates are always set to the end of the month.
>>
>> On Fri, 17 Jan, 2025, 7:22 pm Pranay Patil, <pra...@cr...> wrote:
>>
>>>
>>
>>> I am encountering an issue with the Schedule class in QuantLib while trying to generate a payment schedule. Below is the scenario I am working with:
>>>
>>> Issue Date: 1 January 2025
>>> Maturity Date: 31 August 2025
>>> First Stub Date: 31 January 2025
>>> Calendar Holiday: 31 March 2025 (specified in the calendar)
>>> End-of-Month (EOM): True
>>>
>>> this is my Code snippet
>>> payment_schedule = ql.Schedule(
>>> issueDate,
>>> maturityDate,
>>> ql.Period(fromFrequency),
>>> calendar,
>>> ql.Following,
>>> ql.Unadjusted,
>>> dategeneration,
>>> eom,
>>> firststubdate
>>> )
>>>
>>> Even though I have specified ql.Following for the date adjustment convention, the schedule generates a date of 30 March 2025 instead of the expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month (EOM) flag being set to True, I expected the date to roll forward to 1 April 2025.
>>>
>>> My evaluation is Schedule class is giving preference to the 'eom' flag, not allowing me to choose next month's date according to the ql.Following
>>> Can u help me with this how can i approach this problem
>>>
>>> Thanks
>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Pranay P. <pra...@cr...>]

Thanks, I'll look into it.

On Sat, 18 Jan 2025 at 12:51 AM, Trent Maetzold <tr...@ma...> wrote:

> Someone might be able to give clarification on this, but the schedule
> should determine the accrual schedule. You can have payments adjusted by
> specifying following and eom = false on the actual instrument (so that the
> cashflows get discounted correctly).
>
>
> -------- Original Message --------
>
> On 1/17/25 11:18, Pranay Patil wrote:
>
> Thank you for the clarification.
>
> On Fri, 17 Jan 2025 at 8:21 PM, Roshan Yadav <er....@gm...>
> wrote:
>
>> QuantLib applies the EOM (End of Month) rule, overriding the standard
>> convention, which ensures that payment dates are always set to the end of
>> the month.
>>
>> On Fri, 17 Jan, 2025, 7:22 pm Pranay Patil, <
>> pra...@cr...> wrote:
>>
>>>   I am encountering an issue with the Schedule class in QuantLib while
>>> trying to generate a payment schedule. Below is the scenario I am working
>>> with:
>>>
>>> *Issue Date:* 1 January 2025
>>> *Maturity Date:* 31 August 2025
>>> *First Stub Date:* 31 January 2025
>>> *Calendar Holiday:* 31 March 2025 (specified in the calendar)
>>> *End-of-Month (EOM):* True
>>>
>>> this is my Code snippet
>>> payment_schedule = ql.Schedule(
>>>     issueDate,
>>>     maturityDate,
>>>     ql.Period(fromFrequency),
>>>     calendar,
>>>     ql.Following,
>>>     ql.Unadjusted,
>>>     dategeneration,
>>>     eom,
>>>     firststubdate
>>> )
>>>
>>>   Even though I have specified ql.Following for the date adjustment
>>> convention, the schedule generates a date of 30 March 2025 instead of the
>>> expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month
>>> (EOM) flag being set to True, I expected the date to roll forward to 1
>>> April 2025.
>>>
>>> My evaluation is Schedule class is giving preference to the 'eom' flag,
>>> not allowing me to choose next month's date according to the ql.Following
>>> Can u help me with this how can i approach this  problem
>>>
>>> Thanks
>>>
>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Pranay P. <pra...@cr...>]

Thank you for the clarification.

On Fri, 17 Jan 2025 at 8:21 PM, Roshan Yadav <er....@gm...> wrote:

> QuantLib applies the EOM (End of Month) rule, overriding the standard
> convention, which ensures that payment dates are always set to the end of
> the month.
>
> On Fri, 17 Jan, 2025, 7:22 pm Pranay Patil, <
> pra...@cr...> wrote:
>
>>   I am encountering an issue with the Schedule class in QuantLib while
>> trying to generate a payment schedule. Below is the scenario I am working
>> with:
>>
>> *Issue Date:* 1 January 2025
>> *Maturity Date:* 31 August 2025
>> *First Stub Date:* 31 January 2025
>> *Calendar Holiday:* 31 March 2025 (specified in the calendar)
>> *End-of-Month (EOM):* True
>>
>> this is my Code snippet
>> payment_schedule = ql.Schedule(
>>     issueDate,
>>     maturityDate,
>>     ql.Period(fromFrequency),
>>     calendar,
>>     ql.Following,
>>     ql.Unadjusted,
>>     dategeneration,
>>     eom,
>>     firststubdate
>> )
>>
>>   Even though I have specified ql.Following for the date adjustment
>> convention, the schedule generates a date of 30 March 2025 instead of the
>> expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month
>> (EOM) flag being set to True, I expected the date to roll forward to 1
>> April 2025.
>>
>> My evaluation is Schedule class is giving preference to the 'eom' flag,
>> not allowing me to choose next month's date according to the ql.Following
>> Can u help me with this how can i approach this  problem
>>
>> Thanks
>>
> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Roshan Y. <er....@gm...>]

QuantLib applies the EOM (End of Month) rule, overriding the standard
convention, which ensures that payment dates are always set to the end of
the month.

On Fri, 17 Jan, 2025, 7:22 pm Pranay Patil, <
pra...@cr...> wrote:

>   I am encountering an issue with the Schedule class in QuantLib while
> trying to generate a payment schedule. Below is the scenario I am working
> with:
>
> *Issue Date:* 1 January 2025
> *Maturity Date:* 31 August 2025
> *First Stub Date:* 31 January 2025
> *Calendar Holiday:* 31 March 2025 (specified in the calendar)
> *End-of-Month (EOM):* True
>
> this is my Code snippet
> payment_schedule = ql.Schedule(
>     issueDate,
>     maturityDate,
>     ql.Period(fromFrequency),
>     calendar,
>     ql.Following,
>     ql.Unadjusted,
>     dategeneration,
>     eom,
>     firststubdate
> )
>
>   Even though I have specified ql.Following for the date adjustment
> convention, the schedule generates a date of 30 March 2025 instead of the
> expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month
> (EOM) flag being set to True, I expected the date to roll forward to 1
> April 2025.
>
> My evaluation is Schedule class is giving preference to the 'eom' flag,
> not allowing me to choose next month's date according to the ql.Following
> Can u help me with this how can i approach this  problem
>
> Thanks
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Issue with Payment Schedule in QuantLib Python

[Pranay P. <pra...@cr...>]

  I am encountering an issue with the Schedule class in QuantLib while
trying to generate a payment schedule. Below is the scenario I am working
with:

*Issue Date:* 1 January 2025
*Maturity Date:* 31 August 2025
*First Stub Date:* 31 January 2025
*Calendar Holiday:* 31 March 2025 (specified in the calendar)
*End-of-Month (EOM):* True

this is my Code snippet
payment_schedule = ql.Schedule(
    issueDate,
    maturityDate,
    ql.Period(fromFrequency),
    calendar,
    ql.Following,
    ql.Unadjusted,
    dategeneration,
    eom,
    firststubdate
)

  Even though I have specified ql.Following for the date adjustment
convention, the schedule generates a date of 30 March 2025 instead of the
expected 1 April 2025. Given the holiday on 31 March 2025 and the End-of-Month
(EOM) flag being set to True, I expected the date to roll forward to 1
April 2025.

My evaluation is Schedule class is giving preference to the 'eom' flag, not
allowing me to choose next month's date according to the ql.Following
Can u help me with this how can i approach this  problem

Thanks

[Quantlib-users] Unexpected rate given on last day of month when using OvernightIndexFutureRateHelper

[Emily B. <Emi...@ch...>]

Hello,

I am trying to use QuantLib to build a yield curve using the OvernightIndexFutureRateHelper and FedFunds future prices, but am getting some unexpected results. When the evaluation date is the last day of the month (say, October 31, 2024) the future price for that month (in this case, October) does not affect the rate produced.

Here is a minimal example in Python:


reference_date = ql.Date(31,10,2024)
im = ql.IndexManager.instance()
day_counter = ql.Actual360()
ql.Settings.instance().evaluationDate = reference_date

ff_index = ql.FedFunds()
im.clearHistory(ff_index.name())

fixing_price = 0.05
date = ql.Date(1,10,2024)

while date < reference_date:
    ff_index.addFixing(date, fixing_price)
    date = ff_index.fixingCalendar().advance(date, 1, ql.Days)

ff_helpers = []

quoted_rates = [
    (ql.QuoteHandle(ql.SimpleQuote(94)), ql.Date(31, 10, 2024)),
    (ql.QuoteHandle(ql.SimpleQuote(95)), ql.Date(30, 11, 2024)),
]

for rate, date in quoted_rates:
    ff_helpers.append(ql.OvernightIndexFutureRateHelper(rate, reference_date, date, ff_index))

ff_yield_curve = ql.PiecewiseFlatForward(reference_date, ff_helpers, day_counter, [], [])

curve_dates = [min(ff_yield_curve.dates()) + x for x in range(max(ff_yield_curve.dates()) - min(ff_yield_curve.dates()))]
zero_rates = [round(ff_yield_curve.zeroRate(d, day_counter, ql.Compounded).rate() * 100, 6) for d in curve_dates]

pd.DataFrame(data={'Date': curve_dates, 'ZeroRate': zero_rates})


No matter what price is set for the October 31, 2024 FedFunds future, the resulting rate does not change.

Is this a bug, or is there a more recommended way of setting this up?

Thanks,
Emily






This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. CTC London Limited is authorized and regulated by the Financial Conduct Authority.