quantlib-users — QuantLib users discussion list

[Quantlib-users] bond() to bond helper

[Philippe H. <phi...@ex...>]

Hi.
Is there a function to convert a ql.bond() to a bond helper that would keep
all the parameters? I have a number of US treasury bond instances that I
use and I'd like to build a curve from them.


Regards

Philippe

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] Test-suite Target required strange version of BOOST

[Wei Li <ttl...@gm...>]

Thank you Steven for letting me know how Boost picks up the term VC142. And
thank you Luigi for pointing out that all other projects only use Boost
headers while test-suites uses Boost compiled libraries. And when these
things are made clear, it is quite obvious (and I have confirmed) that my
machine doesn't use VC141 toolset as I intend when I am building.

I believe the problem is even though I specified the "preferredGenerator"
in cmake-tools-kits.json, VS code doesn't respect it and still decides to
use ninja as the generator which uses the default toolset (142) on my
machine. Either the name of this setting is misleading or this is a bug.
There seems to be a report on this issue:

https://github.com/microsoft/vscode-cmake-tools/issues/1084

I end up with installing 142 version of Boost on my machine. And this time
all cmake targets get built without error. We'll install 142 toolset on our
building machine.

Thank you all for your help!

Wei



On Tue, May 19, 2020 at 2:53 PM Luigi Ballabio <lui...@gm...>
wrote:

> Wei,
>     just to check, are you sure that your IDE is using the VS2017 tools?
> (The other projects only use Boost headers, not the libraries, so they
> would compile without errors anyway.)  As Steven says, the version of Boost
> is picked up by <boost/config/auto_link.hpp> which in turn uses _MSC_VER,
> supplied by the compiler.
>
> If this doesn't help, you might try the Boost mailing list.
>
> Regards,
>     Luigi
>
>
> On Mon, May 18, 2020 at 4:47 PM <sh...@op...> wrote:
>
>> Hi Wei,
>>
>>
>>
>> I think the boost auto linking is throwing a spanner in the works. You
>> can find this where <boost/config/auto_link.hpp> is included in
>> quantlibtestsuite.cpp.
>>
>> This will define BOOST_LIB_TOOLSET at compile time.
>>
>>
>>
>> That is probably where the unexpected **vc142** is introduced.
>>
>>
>>
>> Kind Regards,
>>
>> Steven
>>
>>
>>
>>
>>
>>
>>
>> *From:* Wei Li <ttl...@gm...>
>> *Sent:* Monday, 18 May 2020 15:41
>> *To:* QuantLib users <qua...@li...>
>> *Subject:* [Quantlib-users] Test-suite Target required strange version
>> of BOOST
>>
>>
>>
>> Dear all,
>>
>> I am having problem building test-suite on my Windows dev machine using
>> VS Code and CMake. I have Visual Studio 2019 Commodity installed and I have
>> added vc141 build tools from the VS installer (because our build machine
>> only has VS 2017). Then I installed binary boost of version 1.71.0 (VC141).
>>
>> I have chosen these tools because even though we are using QuantLib on
>> Windows machines right now, we'd like to use the same code (which we
>> modified from original QL) on Linux machines at the same time. And we hope
>> to use the same cmake files and maybe the same IDE (VS Code).
>>
>> Firstly I am trying to build the original QuantLib (1.19-dev from github)
>> and I haven't modified any source code nor cmake files. I select a cmake
>> kit whose preferred generator is "Visual Studio 15 2017". And then I run
>> CMake Build (after the CMake configuring). Everything else gets built
>> except for the quantlib-test-suite target. The build fails with the a
>> linker error: "fatal error LNK1104: cannot open file
>> 'libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib'".
>>
>> This is the part that confuses me because all other projects seem fine to
>> be built using *vc141* libraries of boost that I installed (all resides in
>> the same lib64-msvc-14.1 folder). By running CMake configure command for
>> this target, I can see an output "Found Boost: C:/local/boost_1_71_0 (found
>> version "1.71.0") found components: unit_test_framework timer system
>> chrono". These are the four libraries required by test-suite. But
>> apparently they are not the ones required during the building. I am able to
>> finally build this target by doing two things: 1) I make copies of the four
>> mentioned libraries of vc141 and rename them as *vc142*, and 2) excplicitly
>> added these newly-created files to the "target_link_libraries" part of
>> CMakeLists.txt of test-suite. Something like this:
>>
>>
>>
>>
>>
>>
>> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib
>>
>> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_timer-vc142-mt-gd-x64-1_71.lib
>>
>> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_chrono-vc142-mt-gd-x64-1_71.lib
>>
>> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_system-vc142-mt-gd-x64-1_71.lib
>>
>>
>>
>> Clearly this is not optimal because we can't even get it built on another
>> Windows machine which has Boost installed on a different folder. So what I
>> am missing here? I have to admit that I think we ran into the similar thing
>> when we were building in Visual Studio for Windows platform. And there we
>> made it work by copying-renaming the library files. But I am hoping I can
>> solve it this time using a more robust way. Any help would be appreciated.
>> Thank you very much!
>>
>>
>>
>> Cheers,
>>
>> Wei
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

[Quantlib-users] cir process/ quantlib python

[stefano p. <pi...@ya...>]

hello,
is it possible to simulate the CIR (cox ingersoll ross) model (given that i have the 3 parameters and initial value of the process) using some of the quantlib/python function in a similar way as i can for example simulate the geometric brownian motion by using the quantlib constructor "Quantlib.GeometricBrownianMotionProcess"?

i can create a function that simulate the CIR with python, but i would like to use it then into the quantlib function GaussianMultiPathGenerator therefore i need a "quantlib process".

i believe quantlib c++ has the CIR process. maybe i can build the process in quantlib python by starting from StochasticProcess1D? not much documentation on that, though

Inviato da Yahoo Mail su Android

Re: [Quantlib-users] Test-suite Target required strange version of BOOST

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

Wei,
    just to check, are you sure that your IDE is using the VS2017 tools?
(The other projects only use Boost headers, not the libraries, so they
would compile without errors anyway.)  As Steven says, the version of Boost
is picked up by <boost/config/auto_link.hpp> which in turn uses _MSC_VER,
supplied by the compiler.

If this doesn't help, you might try the Boost mailing list.

Regards,
    Luigi


On Mon, May 18, 2020 at 4:47 PM <sh...@op...> wrote:

> Hi Wei,
>
>
>
> I think the boost auto linking is throwing a spanner in the works. You can
> find this where <boost/config/auto_link.hpp> is included in
> quantlibtestsuite.cpp.
>
> This will define BOOST_LIB_TOOLSET at compile time.
>
>
>
> That is probably where the unexpected **vc142** is introduced.
>
>
>
> Kind Regards,
>
> Steven
>
>
>
>
>
>
>
> *From:* Wei Li <ttl...@gm...>
> *Sent:* Monday, 18 May 2020 15:41
> *To:* QuantLib users <qua...@li...>
> *Subject:* [Quantlib-users] Test-suite Target required strange version of
> BOOST
>
>
>
> Dear all,
>
> I am having problem building test-suite on my Windows dev machine using VS
> Code and CMake. I have Visual Studio 2019 Commodity installed and I have
> added vc141 build tools from the VS installer (because our build machine
> only has VS 2017). Then I installed binary boost of version 1.71.0 (VC141).
>
> I have chosen these tools because even though we are using QuantLib on
> Windows machines right now, we'd like to use the same code (which we
> modified from original QL) on Linux machines at the same time. And we hope
> to use the same cmake files and maybe the same IDE (VS Code).
>
> Firstly I am trying to build the original QuantLib (1.19-dev from github)
> and I haven't modified any source code nor cmake files. I select a cmake
> kit whose preferred generator is "Visual Studio 15 2017". And then I run
> CMake Build (after the CMake configuring). Everything else gets built
> except for the quantlib-test-suite target. The build fails with the a
> linker error: "fatal error LNK1104: cannot open file
> 'libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib'".
>
> This is the part that confuses me because all other projects seem fine to
> be built using *vc141* libraries of boost that I installed (all resides in
> the same lib64-msvc-14.1 folder). By running CMake configure command for
> this target, I can see an output "Found Boost: C:/local/boost_1_71_0 (found
> version "1.71.0") found components: unit_test_framework timer system
> chrono". These are the four libraries required by test-suite. But
> apparently they are not the ones required during the building. I am able to
> finally build this target by doing two things: 1) I make copies of the four
> mentioned libraries of vc141 and rename them as *vc142*, and 2) excplicitly
> added these newly-created files to the "target_link_libraries" part of
> CMakeLists.txt of test-suite. Something like this:
>
>
>
>
>
>
> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib
>
> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_timer-vc142-mt-gd-x64-1_71.lib
>
> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_chrono-vc142-mt-gd-x64-1_71.lib
>
> C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_system-vc142-mt-gd-x64-1_71.lib
>
>
>
> Clearly this is not optimal because we can't even get it built on another
> Windows machine which has Boost installed on a different folder. So what I
> am missing here? I have to admit that I think we ran into the similar thing
> when we were building in Visual Studio for Windows platform. And there we
> made it work by copying-renaming the library files. But I am hoping I can
> solve it this time using a more robust way. Any help would be appreciated.
> Thank you very much!
>
>
>
> Cheers,
>
> Wei
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Test-suite Target required strange version of BOOST

[<sh...@op...>]

Hi Wei,

 

I think the boost auto linking is throwing a spanner in the works. You can find this where <boost/config/auto_link.hpp> is included in quantlibtestsuite.cpp.

This will define BOOST_LIB_TOOLSET at compile time.

 

That is probably where the unexpected *vc142* is introduced.

 

Kind Regards,

Steven

 

 

 

From: Wei Li <ttl...@gm...> 
Sent: Monday, 18 May 2020 15:41
To: QuantLib users <qua...@li...>
Subject: [Quantlib-users] Test-suite Target required strange version of BOOST

 

Dear all,

I am having problem building test-suite on my Windows dev machine using VS Code and CMake. I have Visual Studio 2019 Commodity installed and I have added vc141 build tools from the VS installer (because our build machine only has VS 2017). Then I installed binary boost of version 1.71.0 (VC141).

I have chosen these tools because even though we are using QuantLib on Windows machines right now, we'd like to use the same code (which we modified from original QL) on Linux machines at the same time. And we hope to use the same cmake files and maybe the same IDE (VS Code).

Firstly I am trying to build the original QuantLib (1.19-dev from github) and I haven't modified any source code nor cmake files. I select a cmake kit whose preferred generator is "Visual Studio 15 2017". And then I run CMake Build (after the CMake configuring). Everything else gets built except for the quantlib-test-suite target. The build fails with the a linker error: "fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib'". 

This is the part that confuses me because all other projects seem fine to be built using *vc141* libraries of boost that I installed (all resides in the same lib64-msvc-14.1 folder). By running CMake configure command for this target, I can see an output "Found Boost: C:/local/boost_1_71_0 (found version "1.71.0") found components: unit_test_framework timer system chrono". These are the four libraries required by test-suite. But apparently they are not the ones required during the building. I am able to finally build this target by doing two things: 1) I make copies of the four mentioned libraries of vc141 and rename them as *vc142*, and 2) excplicitly added these newly-created files to the "target_link_libraries" part of CMakeLists.txt of test-suite. Something like this:

 

 

C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_timer-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_chrono-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_system-vc142-mt-gd-x64-1_71.lib

 

Clearly this is not optimal because we can't even get it built on another Windows machine which has Boost installed on a different folder. So what I am missing here? I have to admit that I think we ran into the similar thing when we were building in Visual Studio for Windows platform. And there we made it work by copying-renaming the library files. But I am hoping I can solve it this time using a more robust way. Any help would be appreciated. Thank you very much!

 

Cheers,

Wei

[Quantlib-users] Test-suite Target required strange version of BOOST

[Wei Li <ttl...@gm...>]

Dear all,

I am having problem building test-suite on my Windows dev machine using VS
Code and CMake. I have Visual Studio 2019 Commodity installed and I have
added vc141 build tools from the VS installer (because our build machine
only has VS 2017). Then I installed binary boost of version 1.71.0 (VC141).

I have chosen these tools because even though we are using QuantLib on
Windows machines right now, we'd like to use the same code (which we
modified from original QL) on Linux machines at the same time. And we hope
to use the same cmake files and maybe the same IDE (VS Code).

Firstly I am trying to build the original QuantLib (1.19-dev from github)
and I haven't modified any source code nor cmake files. I select a cmake
kit whose preferred generator is "Visual Studio 15 2017". And then I run
CMake Build (after the CMake configuring). Everything else gets built
except for the quantlib-test-suite target. The build fails with the a
linker error: "fatal error LNK1104: cannot open file
'libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib'".

This is the part that confuses me because all other projects seem fine to
be built using *vc141* libraries of boost that I installed (all resides in
the same lib64-msvc-14.1 folder). By running CMake configure command for
this target, I can see an output "Found Boost: C:/local/boost_1_71_0 (found
version "1.71.0") found components: unit_test_framework timer system
chrono". These are the four libraries required by test-suite. But
apparently they are not the ones required during the building. I am able to
finally build this target by doing two things: 1) I make copies of the four
mentioned libraries of vc141 and rename them as *vc142*, and 2) excplicitly
added these newly-created files to the "target_link_libraries" part of
CMakeLists.txt of test-suite. Something like this:


C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_unit_test_framework-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_timer-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_chrono-vc142-mt-gd-x64-1_71.lib
C:\\local\\boost_1_71_0\\lib64-msvc-14.1\\libboost_system-vc142-mt-gd-x64-1_71.lib


Clearly this is not optimal because we can't even get it built on another
Windows machine which has Boost installed on a different folder. So what I
am missing here? I have to admit that I think we ran into the similar thing
when we were building in Visual Studio for Windows platform. And there we
made it work by copying-renaming the library files. But I am hoping I can
solve it this time using a more robust way. Any help would be appreciated.
Thank you very much!

Cheers,
Wei

Re: [Quantlib-users] Svensson fitting

[Frederick D. <fre...@ri...>]

Hi everyone,

Just to know if someone can give some tips here.

Thanks



From: Frederick Delaroche<mailto:fre...@ri...>
Sent: Friday, May 15, 2020 7:06 PM
To: qua...@li...<mailto:qua...@li...>
Subject: Svensson fitting

Hi all,

I am using FittingBondDiscountCurve, Svensson fitting method. Fitting is working nicely; however, I wanted to add a specific control over change in quotes (i.e. no constraint on Svensson parameters) to keep the fitted quote within a given range (e.g. a bid / ask).


  *   Is there any way to do this with QuantLib?

I have tried a basic solution (modifying the FittingCost::values function by changing the error when error itself was above (or below) a given value), but it doesn’t work as expected: depending on the limit, I don’t find the optimal values for the fitted quotes.

“Not find the optimal values” means:

  *   If I don’t have any limit for quotes move, I have a set of fitted quotes. If I check the max error compared to orginal quotes and if I set this move as the limit, I will find a different set of fitted quotes which give a “worse” discount curve.

Thanks for your help.

Rgds,

  *

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Peter C. <pca...@gm...>]

Hi Mario, 

I would hope that you can remove the positivity constraint on the reversion by replacing PositiveConstraint() with NoConstraint() here

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L30 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L30>

and if(_a < …) by if(std::fabs(_a) < …) at these places here

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L38 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L38>

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L51 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L51>

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L65 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/vasicek.cpp#L65>

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/hullwhite.cpp#L95 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/hullwhite.cpp#L95>

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/hullwhite.cpp#L113 <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/hullwhite.cpp#L113>

However I did not try that, so I am not sure if there is more code to amend or whether maybe the code even exploits that the reversion is >= 0 somewhere. If this turns out to be a rabbit hole, you can alternatively use the GSR model (which is the Hull White Model in the T-Forward Measure), here I am sure that it handles negative reversions correctly:

https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/gsr.hpp <https://github.com/lballabio/QuantLib/blob/master/ql/models/shortrate/onefactormodels/gsr.hpp>

Thanks
Peter

> On 16 May 2020, at 21:31, Mario Rossi <df...@gm...> wrote:
> 
> Thanks Peter, for your reply. I tested several other co termination pairs (from 36 to 360 months) getting the following values
> 36 a = 0.00002, sigma = 0.00242 (computed using 2 swaptions) Cumulative Error :         0.04545
> 48 a = 0.00022, sigma = 0.00291 (computed using 3 swaptions) Cumulative Error :         0.10279
> 60 a = 0.00015, sigma = 0.00331 (computed using 3 swaptions) Cumulative Error :         0.07230
> 72 a = 0.00009, sigma = 0.00375 (computed using 4 swaptions) Cumulative Error :         0.15382
> 84 a = 0.00018, sigma = 0.00401 (computed using 4 swaptions) Cumulative Error :         0.09864
> 96 a = 0.00033, sigma = 0.00427 (computed using 4 swaptions) Cumulative Error :         0.07222
> 108 a = 0.00023, sigma = 0.00451 (computed using 4 swaptions) Cumulative Error :         0.05127
> 120 a = 0.00023, sigma = 0.00471 (computed using 4 swaptions) Cumulative Error :         0.03817
> 180 a = 0.00005, sigma = 0.00545 (computed using 2 swaptions) Cumulative Error :         0.00764
> 300 a = 0.00103, sigma = 0.00551 (computed using 4 swaptions) Cumulative Error :         0.01931
> 360 a = 0.00298, sigma = 0.00551 (computed using 5 swaptions) Cumulative Error :         0.01233
> My interest is to calibrate the HW model to generate mark-to-market rather than pricing single swaption.
> If you point me which C++ file I should modify it would be definitely interesting to check whether the reversion value becomes negative.
> Thanks again!
> Mario
> 
> Il giorno ven 15 mag 2020 alle ore 19:47 Peter Caspers <pca...@gm... <mailto:pca...@gm...>> ha scritto:
> A mean reversion close to zero is not unreasonable, you even see negative values used nowadays (although I think the QuantLib::HullWhite model has a positivity constraint built in - something to modernise in my opinion). Looking at the your market vols which are increasing in option expiry direction (I assume) it’s not impossible that the optimal reversion value is actually negative for your case. That would be interesting to see maybe? This requires a small code change on the C++ level though, but we can help you with this if you are interested.
> Best Regards, Peter
> 
>> On 13 May 2020, at 16:25, Mario Rossi <df...@gm... <mailto:df...@gm...>> wrote:
>> 
>> This is a typical result I get with a co-termination set equal to 120 months (there are 4 corresponding swaptions in the volatility matrix).
>> a = 0.00023, sigma = 0.00471
>> ----------------------------------------------------------------------------------
>>     Model Price    Market Price     Implied Vol      Market Vol       Rel Error
>> ----------------------------------------------------------------------------------
>>         0.00194         0.00190         0.00474         0.00464         0.02057
>>         0.00549         0.00542         0.00474         0.00468         0.01177
>>         0.01013         0.01010         0.00473         0.00472         0.00306
>>         0.01746         0.01799         0.00473         0.00488        -0.02976
>> ----------------------------------------------------------------------------------
>> Cumulative Error :         0.03817
>> To me it looks good from the precision viewpoint. However, the resulting value of a (0.00023) looks too small for using it for the
>> generation of HW scenarios. My "feeling" is that the value of should be multiplied by 100  (bringing it equal to 0.023). Am I missing something?
>> Should the resulting value of sigma must be "normalized" in turn?
>> Thanks again!
>> Mario
>> 
>> Il giorno mar 12 mag 2020 alle ore 20:21 Francis Duffy <fdf...@gm... <mailto:fdf...@gm...>> ha scritto:
>> Hi Mario,
>> 
>> No problem.
>> 
>> Thanks,
>> Francis.
>> 
>> On Tue, May 12, 2020 at 5:57 PM Mario Rossi <df...@gm... <mailto:df...@gm...>> wrote:
>> Thanks Francis, dividing by 10000 improves a lot!
>> I understand that finding the "right" combinations of expiries and tenors for the calibration is more an art than a science. 
>> I have to carry out many tests...
>> Thanks again,
>> Mario
>> 
>> Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <fdf...@gm... <mailto:fdf...@gm...>> ha scritto:
>> Hi Mario,
>> 
>> The values in the Excel sheet are normal volatility values expressed in bps so you need to divide them by 10,000 instead of 100. Hopefully that yields results more in line with what you were expecting.
>> 
>> Thanks,
>> Francis. 
>> 
>> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm... <mailto:df...@gm...>> wrote:
>> https://sourceforge.net/p/quantlib/mailman/message/36224288/ <https://sourceforge.net/p/quantlib/mailman/message/36224288/>
>> Hello, I have an issue similar to that described in the above thread.
>> I am trying to calibrate a Hull-White one-factor model using a swaption normal volatility matrix taken few days from Bloomberg (attached as excel file). 
>> I am using basically the same code as described in the above thread (also attached) and I find
>> pretty strange results (a is very low and sigma seems to be pretty high). I wonder if I need
>> to modify, somehow, the volatilities values (besides dividing them by 100).
>> To call the script
>> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
>> (using expiries up to 5 years and just two tenors)
>> Thanks in advance for any help and best regards,
>> Mario
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li... <mailto:Qua...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li... <mailto:Qua...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
> 

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Mario R. <df...@gm...>]

Thanks Peter, for your reply. I tested several other co termination pairs
(from 36 to 360 months) getting the following values
36 a = 0.00002, sigma = 0.00242 (computed using 2 swaptions) Cumulative
Error :         0.04545
48 a = 0.00022, sigma = 0.00291 (computed using 3 swaptions) Cumulative
Error :         0.10279
60 a = 0.00015, sigma = 0.00331 (computed using 3 swaptions) Cumulative
Error :         0.07230
72 a = 0.00009, sigma = 0.00375 (computed using 4 swaptions) Cumulative
Error :         0.15382
84 a = 0.00018, sigma = 0.00401 (computed using 4 swaptions) Cumulative
Error :         0.09864
96 a = 0.00033, sigma = 0.00427 (computed using 4 swaptions) Cumulative
Error :         0.07222
108 a = 0.00023, sigma = 0.00451 (computed using 4 swaptions) Cumulative
Error :         0.05127
120 a = 0.00023, sigma = 0.00471 (computed using 4 swaptions) Cumulative
Error :         0.03817
180 a = 0.00005, sigma = 0.00545 (computed using 2 swaptions) Cumulative
Error :         0.00764
300 a = 0.00103, sigma = 0.00551 (computed using 4 swaptions) Cumulative
Error :         0.01931
360 a = 0.00298, sigma = 0.00551 (computed using 5 swaptions) Cumulative
Error :         0.01233
My interest is to calibrate the HW model to generate mark-to-market rather
than pricing single swaption.
If you point me which C++ file I should modify it would be definitely
interesting to check whether the reversion value becomes negative.
Thanks again!
Mario

Il giorno ven 15 mag 2020 alle ore 19:47 Peter Caspers <
pca...@gm...> ha scritto:

> A mean reversion close to zero is not unreasonable, you even see negative
> values used nowadays (although I think the QuantLib::HullWhite model has a
> positivity constraint built in - something to modernise in my opinion).
> Looking at the your market vols which are increasing in option expiry
> direction (I assume) it’s not impossible that the optimal reversion value
> is actually negative for your case. That would be interesting to see maybe?
> This requires a small code change on the C++ level though, but we can help
> you with this if you are interested.
> Best Regards, Peter
>
> On 13 May 2020, at 16:25, Mario Rossi <df...@gm...> wrote:
>
> This is a typical result I get with a co-termination set equal to 120
> months (there are 4 corresponding swaptions in the volatility matrix).
> a = 0.00023, sigma = 0.00471
>
> ----------------------------------------------------------------------------------
>     Model Price    Market Price     Implied Vol      Market Vol       Rel
> Error
>
> ----------------------------------------------------------------------------------
>         0.00194         0.00190         0.00474         0.00464
> 0.02057
>         0.00549         0.00542         0.00474         0.00468
> 0.01177
>         0.01013         0.01010         0.00473         0.00472
> 0.00306
>         0.01746         0.01799         0.00473         0.00488
>  -0.02976
>
> ----------------------------------------------------------------------------------
> Cumulative Error :         0.03817
> To me it looks good from the precision viewpoint. However, the resulting
> value of a (0.00023) looks too small for using it for the
> generation of HW scenarios. My "feeling" is that the value of should be
> multiplied by 100  (bringing it equal to 0.023). Am I missing something?
> Should the resulting value of sigma must be "normalized" in turn?
> Thanks again!
> Mario
>
> Il giorno mar 12 mag 2020 alle ore 20:21 Francis Duffy <
> fdf...@gm...> ha scritto:
>
>> Hi Mario,
>>
>> No problem.
>>
>> Thanks,
>> Francis.
>>
>> On Tue, May 12, 2020 at 5:57 PM Mario Rossi <df...@gm...> wrote:
>>
>>> Thanks Francis, dividing by 10000 improves a lot!
>>> I understand that finding the "right" combinations of expiries and
>>> tenors for the calibration is more an art than a science.
>>> I have to carry out many tests...
>>> Thanks again,
>>> Mario
>>>
>>> Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <
>>> fdf...@gm...> ha scritto:
>>>
>>>> Hi Mario,
>>>>
>>>> The values in the Excel sheet are normal volatility values expressed in
>>>> bps so you need to divide them by 10,000 instead of 100. Hopefully that
>>>> yields results more in line with what you were expecting.
>>>>
>>>> Thanks,
>>>> Francis.
>>>>
>>>> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm...> wrote:
>>>>
>>>>> https://sourceforge.net/p/quantlib/mailman/message/36224288/
>>>>> Hello, I have an issue similar to that described in the above thread.
>>>>> I am trying to calibrate a Hull-White one-factor model using a
>>>>> swaption normal volatility matrix taken few days from Bloomberg (attached
>>>>> as excel file).
>>>>> I am using basically the same code as described in the above thread
>>>>> (also attached) and I find
>>>>> pretty strange results (a is very low and sigma seems to be
>>>>> pretty high). I wonder if I need
>>>>> to modify, somehow, the volatilities values (besides dividing them by
>>>>> 100).
>>>>> To call the script
>>>>> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
>>>>> (using expiries up to 5 years and just two tenors)
>>>>> Thanks in advance for any help and best regards,
>>>>> Mario
>>>>> _______________________________________________
>>>>> 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
>
>
>

Re: [Quantlib-users] How to get information on parameters of typical Python-quantlib function

[Aleksis A. R. <ale...@go...>]

I think this is something that one needs to get used to when starting out - there doesn’t appear to be an official “quantlib python manual” to my knowledge. However, here are a few resources that are quite useful:

David Duarte has this project:
https://quantlib-python-docs.readthedocs.io/en/latest/index.html <https://quantlib-python-docs.readthedocs.io/en/latest/index.html>

Also there’s Ballabio & Balaraman’s:
https://leanpub.com/quantlibpythoncookbook/ <https://leanpub.com/quantlibpythoncookbook/>

There’s a GitHub page for the quantlib C++ library (brace yourself for the several methods not in quantlib python):
https://rkapl123.github.io/QLAnnotatedSource/index.html <https://rkapl123.github.io/QLAnnotatedSource/index.html>

QuantlibXL has a useful manual for the quantlib xll addin:
https://www.quantlib.org/quantlibxl/categories.html <https://www.quantlib.org/quantlibxl/categories.html>

Finally, the debugging window within your python IDE itself gives pretty useful information on class arguments etc when coding. 

> On 16 May 2020, at 18:59, Christofer Bogaso <bog...@gm...> wrote:
> 
> Hi,
> 
> I am new to Quantlib and started using it through python library. A
> typical start may be -
> 
> import QuantLib as ql
> 
> schedule = ql.Schedule(date1, date2, tenor, calendar, ql.Following,
>                           ql.Following, ql.DateGeneration.Forward, False)
> 
> How can I know about all the input parameters of ql.Schedule like
> underlying classes, what they actually mean etc in a systematic way?
> 
> Sorry if my question is too simple, but appreciate your help.
> 
> Thanks,
> 
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] How to get information on parameters of typical Python-quantlib function

[Christofer B. <bog...@gm...>]

Hi,

I am new to Quantlib and started using it through python library. A
typical start may be -

import QuantLib as ql

schedule = ql.Schedule(date1, date2, tenor, calendar, ql.Following,
                           ql.Following, ql.DateGeneration.Forward, False)

How can I know about all the input parameters of ql.Schedule like
underlying classes, what they actually mean etc in a systematic way?

Sorry if my question is too simple, but appreciate your help.

Thanks,

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Peter C. <pca...@gm...>]

A mean reversion close to zero is not unreasonable, you even see negative values used nowadays (although I think the QuantLib::HullWhite model has a positivity constraint built in - something to modernise in my opinion). Looking at the your market vols which are increasing in option expiry direction (I assume) it’s not impossible that the optimal reversion value is actually negative for your case. That would be interesting to see maybe? This requires a small code change on the C++ level though, but we can help you with this if you are interested.
Best Regards, Peter

> On 13 May 2020, at 16:25, Mario Rossi <df...@gm...> wrote:
> 
> This is a typical result I get with a co-termination set equal to 120 months (there are 4 corresponding swaptions in the volatility matrix).
> a = 0.00023, sigma = 0.00471
> ----------------------------------------------------------------------------------
>     Model Price    Market Price     Implied Vol      Market Vol       Rel Error
> ----------------------------------------------------------------------------------
>         0.00194         0.00190         0.00474         0.00464         0.02057
>         0.00549         0.00542         0.00474         0.00468         0.01177
>         0.01013         0.01010         0.00473         0.00472         0.00306
>         0.01746         0.01799         0.00473         0.00488        -0.02976
> ----------------------------------------------------------------------------------
> Cumulative Error :         0.03817
> To me it looks good from the precision viewpoint. However, the resulting value of a (0.00023) looks too small for using it for the
> generation of HW scenarios. My "feeling" is that the value of should be multiplied by 100  (bringing it equal to 0.023). Am I missing something?
> Should the resulting value of sigma must be "normalized" in turn?
> Thanks again!
> Mario
> 
> Il giorno mar 12 mag 2020 alle ore 20:21 Francis Duffy <fdf...@gm... <mailto:fdf...@gm...>> ha scritto:
> Hi Mario,
> 
> No problem.
> 
> Thanks,
> Francis.
> 
> On Tue, May 12, 2020 at 5:57 PM Mario Rossi <df...@gm... <mailto:df...@gm...>> wrote:
> Thanks Francis, dividing by 10000 improves a lot!
> I understand that finding the "right" combinations of expiries and tenors for the calibration is more an art than a science. 
> I have to carry out many tests...
> Thanks again,
> Mario
> 
> Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <fdf...@gm... <mailto:fdf...@gm...>> ha scritto:
> Hi Mario,
> 
> The values in the Excel sheet are normal volatility values expressed in bps so you need to divide them by 10,000 instead of 100. Hopefully that yields results more in line with what you were expecting.
> 
> Thanks,
> Francis. 
> 
> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm... <mailto:df...@gm...>> wrote:
> https://sourceforge.net/p/quantlib/mailman/message/36224288/ <https://sourceforge.net/p/quantlib/mailman/message/36224288/>
> Hello, I have an issue similar to that described in the above thread.
> I am trying to calibrate a Hull-White one-factor model using a swaption normal volatility matrix taken few days from Bloomberg (attached as excel file). 
> I am using basically the same code as described in the above thread (also attached) and I find
> pretty strange results (a is very low and sigma seems to be pretty high). I wonder if I need
> to modify, somehow, the volatilities values (besides dividing them by 100).
> To call the script
> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
> (using expiries up to 5 years and just two tenors)
> Thanks in advance for any help and best regards,
> Mario
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li... <mailto:Qua...@li...>
> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] Svensson fitting

[Frederick D. <fre...@ri...>]

Hi all,

I am using FittingBondDiscountCurve, Svensson fitting method. Fitting is working nicely; however, I wanted to add a specific control over change in quotes (i.e. no constraint on Svensson parameters) to keep the fitted quote within a given range (e.g. a bid / ask).


  *   Is there any way to do this with QuantLib?

I have tried a basic solution (modifying the FittingCost::values function by changing the error when error itself was above (or below) a given value), but it doesn’t work as expected: depending on the limit, I don’t find the optimal values for the fitted quotes.

“Not find the optimal values” means:

  *   If I don’t have any limit for quotes move, I have a set of fitted quotes. If I check the max error compared to orginal quotes and if I set this move as the limit, I will find a different set of fitted quotes which give a “worse” discount curve.

Thanks for your help.

Rgds,

  *

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Mario R. <df...@gm...>]

This is a typical result I get with a co-termination set equal to 120
months (there are 4 corresponding swaptions in the volatility matrix).
a = 0.00023, sigma = 0.00471
----------------------------------------------------------------------------------
    Model Price    Market Price     Implied Vol      Market Vol       Rel
Error
----------------------------------------------------------------------------------
        0.00194         0.00190         0.00474         0.00464
0.02057
        0.00549         0.00542         0.00474         0.00468
0.01177
        0.01013         0.01010         0.00473         0.00472
0.00306
        0.01746         0.01799         0.00473         0.00488
 -0.02976
----------------------------------------------------------------------------------
Cumulative Error :         0.03817
To me it looks good from the precision viewpoint. However, the resulting
value of a (0.00023) looks too small for using it for the
generation of HW scenarios. My "feeling" is that the value of should be
multiplied by 100  (bringing it equal to 0.023). Am I missing something?
Should the resulting value of sigma must be "normalized" in turn?
Thanks again!
Mario

Il giorno mar 12 mag 2020 alle ore 20:21 Francis Duffy <
fdf...@gm...> ha scritto:

> Hi Mario,
>
> No problem.
>
> Thanks,
> Francis.
>
> On Tue, May 12, 2020 at 5:57 PM Mario Rossi <df...@gm...> wrote:
>
>> Thanks Francis, dividing by 10000 improves a lot!
>> I understand that finding the "right" combinations of expiries and tenors
>> for the calibration is more an art than a science.
>> I have to carry out many tests...
>> Thanks again,
>> Mario
>>
>> Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <
>> fdf...@gm...> ha scritto:
>>
>>> Hi Mario,
>>>
>>> The values in the Excel sheet are normal volatility values expressed in
>>> bps so you need to divide them by 10,000 instead of 100. Hopefully that
>>> yields results more in line with what you were expecting.
>>>
>>> Thanks,
>>> Francis.
>>>
>>> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm...> wrote:
>>>
>>>> https://sourceforge.net/p/quantlib/mailman/message/36224288/
>>>> Hello, I have an issue similar to that described in the above thread.
>>>> I am trying to calibrate a Hull-White one-factor model using a swaption
>>>> normal volatility matrix taken few days from Bloomberg (attached as excel
>>>> file).
>>>> I am using basically the same code as described in the above thread
>>>> (also attached) and I find
>>>> pretty strange results (a is very low and sigma seems to be
>>>> pretty high). I wonder if I need
>>>> to modify, somehow, the volatilities values (besides dividing them by
>>>> 100).
>>>> To call the script
>>>> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
>>>> (using expiries up to 5 years and just two tenors)
>>>> Thanks in advance for any help and best regards,
>>>> Mario
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Francis D. <fdf...@gm...>]

Hi Mario,

No problem.

Thanks,
Francis.

On Tue, May 12, 2020 at 5:57 PM Mario Rossi <df...@gm...> wrote:

> Thanks Francis, dividing by 10000 improves a lot!
> I understand that finding the "right" combinations of expiries and tenors
> for the calibration is more an art than a science.
> I have to carry out many tests...
> Thanks again,
> Mario
>
> Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <
> fdf...@gm...> ha scritto:
>
>> Hi Mario,
>>
>> The values in the Excel sheet are normal volatility values expressed in
>> bps so you need to divide them by 10,000 instead of 100. Hopefully that
>> yields results more in line with what you were expecting.
>>
>> Thanks,
>> Francis.
>>
>> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm...> wrote:
>>
>>> https://sourceforge.net/p/quantlib/mailman/message/36224288/
>>> Hello, I have an issue similar to that described in the above thread.
>>> I am trying to calibrate a Hull-White one-factor model using a swaption
>>> normal volatility matrix taken few days from Bloomberg (attached as excel
>>> file).
>>> I am using basically the same code as described in the above thread
>>> (also attached) and I find
>>> pretty strange results (a is very low and sigma seems to be
>>> pretty high). I wonder if I need
>>> to modify, somehow, the volatilities values (besides dividing them by
>>> 100).
>>> To call the script
>>> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
>>> (using expiries up to 5 years and just two tenors)
>>> Thanks in advance for any help and best regards,
>>> Mario
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Mario R. <df...@gm...>]

Thanks Francis, dividing by 10000 improves a lot!
I understand that finding the "right" combinations of expiries and tenors
for the calibration is more an art than a science.
I have to carry out many tests...
Thanks again,
Mario

Il giorno mar 12 mag 2020 alle ore 16:45 Francis Duffy <
fdf...@gm...> ha scritto:

> Hi Mario,
>
> The values in the Excel sheet are normal volatility values expressed in
> bps so you need to divide them by 10,000 instead of 100. Hopefully that
> yields results more in line with what you were expecting.
>
> Thanks,
> Francis.
>
> On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm...> wrote:
>
>> https://sourceforge.net/p/quantlib/mailman/message/36224288/
>> Hello, I have an issue similar to that described in the above thread.
>> I am trying to calibrate a Hull-White one-factor model using a swaption
>> normal volatility matrix taken few days from Bloomberg (attached as excel
>> file).
>> I am using basically the same code as described in the above thread (also
>> attached) and I find
>> pretty strange results (a is very low and sigma seems to be pretty high).
>> I wonder if I need
>> to modify, somehow, the volatilities values (besides dividing them by
>> 100).
>> To call the script
>> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
>> (using expiries up to 5 years and just two tenors)
>> Thanks in advance for any help and best regards,
>> Mario
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Francis D. <fdf...@gm...>]

Hi Mario,

The values in the Excel sheet are normal volatility values expressed in bps
so you need to divide them by 10,000 instead of 100. Hopefully that yields
results more in line with what you were expecting.

Thanks,
Francis.

On Tue, May 12, 2020 at 3:28 PM Mario Rossi <df...@gm...> wrote:

> https://sourceforge.net/p/quantlib/mailman/message/36224288/
> Hello, I have an issue similar to that described in the above thread.
> I am trying to calibrate a Hull-White one-factor model using a swaption
> normal volatility matrix taken few days from Bloomberg (attached as excel
> file).
> I am using basically the same code as described in the above thread (also
> attached) and I find
> pretty strange results (a is very low and sigma seems to be pretty high).
> I wonder if I need
> to modify, somehow, the volatilities values (besides dividing them by 100).
> To call the script
> python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
> (using expiries up to 5 years and just two tenors)
> Thanks in advance for any help and best regards,
> Mario
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Re-Opening of https://sourceforge.net/p/quantlib/mailman/message/36224288/

[Mario R. <df...@gm...>]

https://sourceforge.net/p/quantlib/mailman/message/36224288/
Hello, I have an issue similar to that described in the above thread.
I am trying to calibrate a Hull-White one-factor model using a swaption
normal volatility matrix taken few days from Bloomberg (attached as excel
file).
I am using basically the same code as described in the above thread (also
attached) and I find
pretty strange results (a is very low and sigma seems to be pretty high). I
wonder if I need
to modify, somehow, the volatilities values (besides dividing them by 100).
To call the script
python3 hw1fqlcal.py vol_20200505.xlsx 12 60 12 24
(using expiries up to 5 years and just two tenors)
Thanks in advance for any help and best regards,
Mario

Re: [Quantlib-users] CNY Swap

[Aleksis A. R. <ale...@go...>]

Hi David, a hack that might work is to use ql.Swap and price a fixed/fixed swap with one of legs fed with a vector of rates calculated from the index. You then have flexibility to define the compounding in any way. For example below is a hack to reproduce a vanilla OIS using this method.

# vanilla OIS
ois_sett = calendar.advance(calculation_date,2,ql.Days)
oisstart = calendar.advance(ois_sett,0,ql.Months)
maturity = calendar.advance(oisstart, 2, ql.Years)
schedule = ql.MakeSchedule(oisstart, maturity, ql.Period('3M'), calendar=calendar)
swapType = ql.OvernightIndexedSwap.Payer
index = ql.OvernightIndex('', 2, ql.USDCurrency(), ql.NullCalendar(), ql.Actual360(), libor_curve)
ois = ql.OvernightIndexedSwap(swapType, 100, schedule, 0.0, day_count, index)
ois.setPricingEngine(swap_engine)

# manually calc OIS fixings
ONfixings=[]
for j in range(0,len(schedule)-1):
daysinperiod=[calendar.advance(ois_sett,i,ql.Days) for i in range(0,ql.as_floating_rate_coupon(ois.leg(1)[j]).accrualDays())]
OISfixings_j=[index.fixing(i) for i in daysinperiod]
OISratelist_j=[(1+(1/360)*i) for i in OISfixings_j]
ONfixings.append((np.prod(OISratelist_j) - 1) / ql.as_floating_rate_coupon(ois.leg(1)[j]).accrualPeriod())

# hacked OIS
hackedOISleg=ql.FixedRateLeg(floating_schedule,ql.Actual360(),notional,ONfixings)
hackedOIS=ql.Swap(fixed_leg,hackedOISleg)
hackedOIS.setPricingEngine(swap_engine)



> On 11 May 2020, at 13:51, Amine Ifri <ami...@gm...> wrote:
> 
> Hi David,
> 
> For this one needs to implement a WeeklyCompoundedIndex interface in the C++ library. It is a bit of work imho. Ideally, we should be able to create an interface that takes any compounding frequency and calculate the cumulative payment, but I suspect it is not in the library as of yet. 
> 
> Regards,
> Amine
> 
>> On 11 May 2020, at 13:43, David Duarte <nh...@gm...> wrote:
>> 
>> Hi All,
>> 
>> Has anyone figured out a way to model CNY swaps with QuantLib Python?
>> The issue is that the floating leg in a weekly rate compounded to quarterly payments. So it's not a simple iborIndex nor an overnightIndex.
>> 
>> When creating an overnight index, the tenor is always assumed to be "1D" and that parameter is not in the constructor to be able to change it.
>> 
>> Here is an example which is NOT accurate because the index will have daily fixings and not weekly:
>> 
>> cny_crv = ql.FlatForward(0, ql.China(), 0.03, ql.Actual365Fixed())
>> cny_yts = ql.YieldTermStructureHandle(cny_crv)
>> engine = ql.DiscountingSwapEngine(cny_yts)
>> 
>> calendar = ql.China()
>> start = ql.Date().todaysDate()
>> maturity = calendar.advance(start, 2, ql.Years)
>> schedule = ql.MakeSchedule(start, maturity, ql.Period('3M'), calendar=calendar)
>> 
>> swapType = ql.OvernightIndexedSwap.Payer
>> dc = ql.Actual365Fixed()
>> index = ql.OvernightIndex('CNRR007', 0, ql.CNYCurrency(), ql.China(), ql.Actual365Fixed(), cny_yts)
>> 
>> ois = ql.OvernightIndexedSwap(swapType, 100, schedule, 0.0, dc, index)
>> ois.setPricingEngine(engine)
>> 
>> ois.fairRate()
>> 
>> 
>> Thanks,
>> David
>> 
>> 
>> _______________________________________________
>> 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

Re: [Quantlib-users] CNY Swap

[Amine I. <ami...@gm...>]

Hi David,

For this one needs to implement a WeeklyCompoundedIndex interface in the C++ library. It is a bit of work imho. Ideally, we should be able to create an interface that takes any compounding frequency and calculate the cumulative payment, but I suspect it is not in the library as of yet. 

Regards,
Amine

> On 11 May 2020, at 13:43, David Duarte <nh...@gm...> wrote:
> 
> Hi All,
> 
> Has anyone figured out a way to model CNY swaps with QuantLib Python?
> The issue is that the floating leg in a weekly rate compounded to quarterly payments. So it's not a simple iborIndex nor an overnightIndex.
> 
> When creating an overnight index, the tenor is always assumed to be "1D" and that parameter is not in the constructor to be able to change it.
> 
> Here is an example which is NOT accurate because the index will have daily fixings and not weekly:
> 
> cny_crv = ql.FlatForward(0, ql.China(), 0.03, ql.Actual365Fixed())
> cny_yts = ql.YieldTermStructureHandle(cny_crv)
> engine = ql.DiscountingSwapEngine(cny_yts)
> 
> calendar = ql.China()
> start = ql.Date().todaysDate()
> maturity = calendar.advance(start, 2, ql.Years)
> schedule = ql.MakeSchedule(start, maturity, ql.Period('3M'), calendar=calendar)
> 
> swapType = ql.OvernightIndexedSwap.Payer
> dc = ql.Actual365Fixed()
> index = ql.OvernightIndex('CNRR007', 0, ql.CNYCurrency(), ql.China(), ql.Actual365Fixed(), cny_yts)
> 
> ois = ql.OvernightIndexedSwap(swapType, 100, schedule, 0.0, dc, index)
> ois.setPricingEngine(engine)
> 
> ois.fairRate()
> 
> 
> Thanks,
> David
> 
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] CNY Swap

[David D. <nh...@gm...>]

Hi All,

Has anyone figured out a way to model CNY swaps with QuantLib Python?
The issue is that the floating leg in a weekly rate compounded to quarterly
payments. So it's not a simple iborIndex nor an overnightIndex.

When creating an overnight index, the tenor is always assumed to be "1D"
and that parameter is not in the constructor to be able to change it.

Here is an example which is NOT accurate because the index will have daily
fixings and not weekly:

cny_crv = ql.FlatForward(0, ql.China(), 0.03, ql.Actual365Fixed())
cny_yts = ql.YieldTermStructureHandle(cny_crv)
engine = ql.DiscountingSwapEngine(cny_yts)

calendar = ql.China()
start = ql.Date().todaysDate()
maturity = calendar.advance(start, 2, ql.Years)
schedule = ql.MakeSchedule(start, maturity, ql.Period('3M'),
calendar=calendar)

swapType = ql.OvernightIndexedSwap.Payer
dc = ql.Actual365Fixed()
index = ql.OvernightIndex('CNRR007', 0, ql.CNYCurrency(), ql.China(),
ql.Actual365Fixed(), cny_yts)

ois = ql.OvernightIndexedSwap(swapType, 100, schedule, 0.0, dc, index)
ois.setPricingEngine(engine)

ois.fairRate()


Thanks,
David

Re: [Quantlib-users] [QuantLib-1.18-cp37-cp37m-win_amd64.whl] Incompatible with Python 3.7 x86

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

Ok, it turned out that producing 32-bit wheels takes very little effort.
You can try `pip install QuantLib` now.

Luigi


On Wed, May 6, 2020 at 5:39 PM Laurent Dahan <dah...@gm...>
wrote:

> Ok thanks you so much.
>
> Laurent
>
> Le mer. 6 mai 2020 à 17:33, Luigi Ballabio <lui...@gm...> a
> écrit :
>
>> As far as I know, Python itself is compiled with VS2015.  VS2017 might
>> work, but I haven't tried that.  It might also be possible to install the
>> VS2015 tools inside the VS2017 IDE together with the 2017 ones.
>>
>> Luigi
>>
>>
>> On Wed, May 6, 2020 at 5:28 PM Laurent Dahan <dah...@gm...>
>> wrote:
>>
>>> Hello Luigi,
>>>
>>> Thanks for this very fast answer.
>>> I never did but will try.
>>> I am currently using a VS2017 distrib. Do you think I must install the
>>> VS2012 version first?
>>> Thanks in advance
>>> Best regards
>>>
>>> Laurent
>>>
>>> Le mer. 6 mai 2020 à 17:26, Luigi Ballabio <lui...@gm...> a
>>> écrit :
>>>
>>>> Hi,
>>>>     yes, the available wheels are 64-bit only.  I'm not sure if I'll
>>>> get around to compile 32-bit versions.  In the meantime, can you try
>>>> compiling from source?
>>>>
>>>> Regards,
>>>>     Luigi
>>>>
>>>>
>>>> On Wed, May 6, 2020 at 5:08 PM Laurent Dahan <dah...@gm...>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I am new potential new QuantLib Python user. As part of my initial
>>>>> tests, I am trying to install the latest release on my machine where I have
>>>>> Python 3.7.7 32 bit (I need for compatibility reasons to keep using a 32
>>>>> bits Python version).
>>>>> The problem is that "pip install" refuses to install QuantLib stating
>>>>> that there is no compatible distrib and I figured out that this statement
>>>>> is linked to the fact that I am trying to install it on the 32bit Python
>>>>> version.
>>>>> Do you plan compiling a 32bits version, or is pip message linked to a
>>>>> misunderstanding of this QuantLib-1.18-cp37-cp37m-win_amd64.whl file
>>>>> dependencies?
>>>>> Thanks in advance for your help.
>>>>> Best regards,
>>>>>
>>>>> Laurent Dahan
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>

Re: [Quantlib-users] [QuantLib-1.18-cp37-cp37m-win_amd64.whl] Incompatible with Python 3.7 x86

[Laurent D. <dah...@gm...>]

Ok thanks you so much.

Laurent

Le mer. 6 mai 2020 à 17:33, Luigi Ballabio <lui...@gm...> a
écrit :

> As far as I know, Python itself is compiled with VS2015.  VS2017 might
> work, but I haven't tried that.  It might also be possible to install the
> VS2015 tools inside the VS2017 IDE together with the 2017 ones.
>
> Luigi
>
>
> On Wed, May 6, 2020 at 5:28 PM Laurent Dahan <dah...@gm...>
> wrote:
>
>> Hello Luigi,
>>
>> Thanks for this very fast answer.
>> I never did but will try.
>> I am currently using a VS2017 distrib. Do you think I must install the
>> VS2012 version first?
>> Thanks in advance
>> Best regards
>>
>> Laurent
>>
>> Le mer. 6 mai 2020 à 17:26, Luigi Ballabio <lui...@gm...> a
>> écrit :
>>
>>> Hi,
>>>     yes, the available wheels are 64-bit only.  I'm not sure if I'll get
>>> around to compile 32-bit versions.  In the meantime, can you try compiling
>>> from source?
>>>
>>> Regards,
>>>     Luigi
>>>
>>>
>>> On Wed, May 6, 2020 at 5:08 PM Laurent Dahan <dah...@gm...>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I am new potential new QuantLib Python user. As part of my initial
>>>> tests, I am trying to install the latest release on my machine where I have
>>>> Python 3.7.7 32 bit (I need for compatibility reasons to keep using a 32
>>>> bits Python version).
>>>> The problem is that "pip install" refuses to install QuantLib stating
>>>> that there is no compatible distrib and I figured out that this statement
>>>> is linked to the fact that I am trying to install it on the 32bit Python
>>>> version.
>>>> Do you plan compiling a 32bits version, or is pip message linked to a
>>>> misunderstanding of this QuantLib-1.18-cp37-cp37m-win_amd64.whl file
>>>> dependencies?
>>>> Thanks in advance for your help.
>>>> Best regards,
>>>>
>>>> Laurent Dahan
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>

Re: [Quantlib-users] [QuantLib-1.18-cp37-cp37m-win_amd64.whl] Incompatible with Python 3.7 x86

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

As far as I know, Python itself is compiled with VS2015.  VS2017 might
work, but I haven't tried that.  It might also be possible to install the
VS2015 tools inside the VS2017 IDE together with the 2017 ones.

Luigi


On Wed, May 6, 2020 at 5:28 PM Laurent Dahan <dah...@gm...>
wrote:

> Hello Luigi,
>
> Thanks for this very fast answer.
> I never did but will try.
> I am currently using a VS2017 distrib. Do you think I must install the
> VS2012 version first?
> Thanks in advance
> Best regards
>
> Laurent
>
> Le mer. 6 mai 2020 à 17:26, Luigi Ballabio <lui...@gm...> a
> écrit :
>
>> Hi,
>>     yes, the available wheels are 64-bit only.  I'm not sure if I'll get
>> around to compile 32-bit versions.  In the meantime, can you try compiling
>> from source?
>>
>> Regards,
>>     Luigi
>>
>>
>> On Wed, May 6, 2020 at 5:08 PM Laurent Dahan <dah...@gm...>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I am new potential new QuantLib Python user. As part of my initial
>>> tests, I am trying to install the latest release on my machine where I have
>>> Python 3.7.7 32 bit (I need for compatibility reasons to keep using a 32
>>> bits Python version).
>>> The problem is that "pip install" refuses to install QuantLib stating
>>> that there is no compatible distrib and I figured out that this statement
>>> is linked to the fact that I am trying to install it on the 32bit Python
>>> version.
>>> Do you plan compiling a 32bits version, or is pip message linked to a
>>> misunderstanding of this QuantLib-1.18-cp37-cp37m-win_amd64.whl file
>>> dependencies?
>>> Thanks in advance for your help.
>>> Best regards,
>>>
>>> Laurent Dahan
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] [QuantLib-1.18-cp37-cp37m-win_amd64.whl] Incompatible with Python 3.7 x86

[Laurent D. <dah...@gm...>]

Hello Luigi,

Thanks for this very fast answer.
I never did but will try.
I am currently using a VS2017 distrib. Do you think I must install the
VS2012 version first?
Thanks in advance
Best regards

Laurent

Le mer. 6 mai 2020 à 17:26, Luigi Ballabio <lui...@gm...> a
écrit :

> Hi,
>     yes, the available wheels are 64-bit only.  I'm not sure if I'll get
> around to compile 32-bit versions.  In the meantime, can you try compiling
> from source?
>
> Regards,
>     Luigi
>
>
> On Wed, May 6, 2020 at 5:08 PM Laurent Dahan <dah...@gm...>
> wrote:
>
>> Hi everyone,
>>
>> I am new potential new QuantLib Python user. As part of my initial tests,
>> I am trying to install the latest release on my machine where I have Python
>> 3.7.7 32 bit (I need for compatibility reasons to keep using a 32 bits
>> Python version).
>> The problem is that "pip install" refuses to install QuantLib stating
>> that there is no compatible distrib and I figured out that this statement
>> is linked to the fact that I am trying to install it on the 32bit Python
>> version.
>> Do you plan compiling a 32bits version, or is pip message linked to a
>> misunderstanding of this QuantLib-1.18-cp37-cp37m-win_amd64.whl file
>> dependencies?
>> Thanks in advance for your help.
>> Best regards,
>>
>> Laurent Dahan
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>