quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Docker Windows container

[Alix L. <ali...@gm...>]

Hi Luigi and QL-community,

I was wondering if someone has already experimented with the generation of
a QuantLib-Python wheel from a Docker Windows container.

At the moment, from the various work and contributions I found on the web,
I noticed most of the Docker Linux containers (from ubuntu, alpine, ...),
but none of them with Windows.

I think it could be very helpful to be able to automate the compilation of
QuantLib and QuantLib-SWIG/Python on Windows through command lines
exclusively, and with Docker. I can see several advantages :
- first, Docker would propose an isolated environment
- then, we don't necessarily need to install Visual C++ on our machine
- finally, if the installation relies purely on command lines, this could
make it as tractable as it is already on Linux

What do you think in terms of feasibility and has anyone already tried this
approach?

Thanks for your feedbacks,

Alix

[Quantlib-dev] ORE 7

[Roland L. <rol...@ac...>]

Dear all,

we have just published the 7th release of ORE and ORE-SWIG, updating the codebase at https://github.com/OpenSourceRisk. ORE 7 depends on QuantLib 1.27.1 and QuantLib-SWIG 1.27.

The release contains many fixes and improvements over the past year that were triggered by our main sponsor’s (Acadia) use of ORE in their Initial Margin Risk Generator services.  The full release notes can be found in the user guide under the DOCUMENTATION menu on https://opensourcerisk.org.

With this release we have started publishing a wide range of additional financial instruments. You will see various Equity/FX Exotics in this release. Commodity, Credit, Hybrids, Exotics with scripted payoffs will follow in the next releases in quarterly steps, see also the Acadia press release and roadmap here<https://www.acadia.inc/news/acadia-announces-seventh-release-of-open-source-risk-engine-with-quarterly-releases-to-follow>.

If you want to hear from Acadia about latest ORE developments, then feel free to sign up here<https://share.hsforms.com/1eqcUZ-9_QdSH__M7_YPSig43ul4> to receive updates by email.
Please explore ORE – download the release executable, or clone the repositories and build.

As usual, all feedback is welcome!

Best regards,
Roland

The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. The acadia.inc privacy policy is available on our website.

[Quantlib-dev] QuantLib 1.27.1 released

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

QuantLib 1.27.1 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

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

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

Re: [Quantlib-dev] A double contribution

[Dirk E. <ed...@de...>]

On 26 August 2022 at 15:40, Wojciech Czernous via QuantLib-dev wrote:
| We are considering a two-author contribution with a colleague. 
| It would be based on his Master’s thesis and his code prototype in Python. I would like to do the C++ implementation and tests, and commit it to the repository. 
| Is it possible for us both to become contributors to QuantLib in this process?

Sure, why not?  QuantLib has a long history of including such contributions.

| What are the rules here?

I am not a QuantLib admin but the common process for many open source
projects is for you to fork, and to prepare a clean pull request that updates
code, possibly adds tests, maybe adds an example, ... without affecting
existing code and tests.

| Is becoming a contributor tightly coupled with the git commit authorship?

Pull requests are incremental and do not requirement commit authorship on
your part but only on the part of the core maintainers with such commit
rights who review the pull request contribution. 

Hope this helps,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-dev] A double contribution

[Wojciech C. <woj...@ic...>]

Good afternoon!

We are considering a two-author contribution with a colleague. 
It would be based on his Master’s thesis and his code prototype in Python. I would like to do the C++ implementation and tests, and commit it to the repository. 
Is it possible for us both to become contributors to QuantLib in this process?
What are the rules here?
Is becoming a contributor tightly coupled with the git commit authorship?

Kind regards,
Wojciech Czernous

Re: [Quantlib-dev] Building Quantlib-SWIG

[Jonathan S. <sw...@gm...>]

Hi Francesco,

When you say you want to "build a SWIG interface", do you mean that you
just want to compile QuantLib-SWIG? If so, then you can follow the
instructions here: https://www.quantlib.org/install/linux-python.shtml

Or if you're trying to do something different, would you mind sharing a few
more details on how it's different from what's already provided in
QuantLib-SWIG?

On Sat, Jul 23, 2022 at 4:37 PM Francesco Catalano <cat...@gm...>
wrote:

> Dear Developers,
> I have a configuration of this
>  ---- Folder
>        ---------- Quantlib (this at current master)
>        ---------- Quantlib-SWIG (this at current master)
> I can compile easily quantlib with cmake and I can locate where object
> files and the library are. I want to use Cmake.
> I would like now to basically build a SWIG interface. I technically know
> how to  SWIG interface small projects.  Clearly for a project like QuantLib
> I have to  use disutils. I see a Python folder with setup.py.
> However I can not locate where I can specify the SWIGfiles folder to
> generate the wrapper.cpp and the source code of quantlib and objects files
> in setup.py. Can someone help ?
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Building Quantlib-SWIG

[Francesco C. <cat...@gm...>]

Dear Developers,
I have a configuration of this
 ---- Folder
       ---------- Quantlib (this at current master)
       ---------- Quantlib-SWIG (this at current master)
I can compile easily quantlib with cmake and I can locate where object
files and the library are. I want to use Cmake.
I would like now to basically build a SWIG interface. I technically know
how to  SWIG interface small projects.  Clearly for a project like QuantLib
I have to  use disutils. I see a Python folder with setup.py.
However I can not locate where I can specify the SWIGfiles folder to
generate the wrapper.cpp and the source code of quantlib and objects files
in setup.py. Can someone help ?

[Quantlib-dev] QuantLib 1.27 released

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

QuantLib 1.27 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

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

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

Re: [Quantlib-dev] rough volatility

[Jonathan S. <sw...@gm...>]

Someone recently started experimenting with it on GitHub[1] but not sure
how far they have gotten.

Personally I think it’s a very worthwhile topic to pursue and something
that a lot of other users would find useful as well.

[1]
https://github.com/lballabio/QuantLib/issues/1376

2022년 6월 21일 (화) 16:41, Wojciech Czernous via QuantLib-dev <
qua...@li...>님이 작성:

> Good morning,
>
> I wonder, is there any sense in pursuing the subject of rough volatility
> in the context of QuantLib?
> Thank you very much in advance for your answers!
>
> Kind regards,
> Wojciech Czernous
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] rough volatility

[Wojciech C. <woj...@ic...>]

Good morning,

I wonder, is there any sense in pursuing the subject of rough volatility in the context of QuantLib?
Thank you very much in advance for your answers!

Kind regards,
Wojciech Czernous

Re: [Quantlib-dev] Poll: Remove support for sessionId()

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

Hi

friendly reminder / am I right in interpreting the silence as consent?

Thanks
Peter

On Wed, 11 May 2022 at 09:55, Peter Caspers <pca...@gm...> wrote:
>
> Hi all
>
> When QuantLib is built with enabled QL_ENABLE_SESSIONS, users have to
> provide an implementation of sessionId(). Usually the sessions are
> used to enable thread-local singleton instances and consequently
> sessionId() will be implemented such that the current thread id is
> returned. More recent versions of QuantLib require C++11 as the
> minimum language standard and with that we are able to simplify the
> singleton implementation while always ensuring a thread-safe
> initialization of singleton instances. The proposed change is this
>
> https://github.com/lballabio/QuantLib/pull/1377
>
> and comes with a removal of the sessionId() and a hard-wired
> assumption that there is a 1:1 relation between sessions and threads.
> The question for you is whether there are other uses of sessions out
> there which wouldn't be supported after the above change, i.e. where
> you use sessions differently from what I described above.
>
> Thanks
> Peter

[Quantlib-dev] Poll: Remove support for sessionId()

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

Hi all

When QuantLib is built with enabled QL_ENABLE_SESSIONS, users have to
provide an implementation of sessionId(). Usually the sessions are
used to enable thread-local singleton instances and consequently
sessionId() will be implemented such that the current thread id is
returned. More recent versions of QuantLib require C++11 as the
minimum language standard and with that we are able to simplify the
singleton implementation while always ensuring a thread-safe
initialization of singleton instances. The proposed change is this

https://github.com/lballabio/QuantLib/pull/1377

and comes with a removal of the sessionId() and a hard-wired
assumption that there is a 1:1 relation between sessions and threads.
The question for you is whether there are other uses of sessions out
there which wouldn't be supported after the above change, i.e. where
you use sessions differently from what I described above.

Thanks
Peter

Re: [Quantlib-dev] cmake configured files

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

Hi Jonathan, agreed!
Thanks again
Peter

On Mon, 2 May 2022 at 00:47, Jonathan Sweemer <sw...@gm...> wrote:
>
> Hi Peter,
>
> This part of the CMake build settings was added by @pkovacs. I think the intention may have been to expose QL_HAVE_CONFIG_H as a CMake option with a default of ON instead of always hardcoding it to ON. But as I mentioned, there’s no real compelling use case (in my opinion) for setting it to OFF so I agree that it would be much cleaner to just define HAVE_CONFIG_H in CMakeLists.txt and thereby eliminate the need for configuring qldefines.hpp.
>
> I actually didn’t realize there were two versions of qldefines.hpp - the configured one and the non-configured one. That does indeed seem like a recipe for inconsistency and is reason enough to try and consolidate the two.
>
> Looks like there’s one other inconsistency between the two qldefines.hpp - the define for QL_USE_STD_UNIQUE_PTR was only added to the non-configured one. This should be added to the configured one as well for consistency until a decision is made about whether to configure or not.
>
> Jonathan
>
>
> 2022년 5월 2일 (월) 03:12, Peter Caspers <pca...@gm...>님이 작성:
>>
>> Hi,
>>
>> thanks. I get how it works. My question is if the code duplication in
>> qldefines.hpp / qldefines.hpp.cfg can be avoided by defining the macro
>> HAVE_CONFIG_H in the cmake build, just as we do in the autoconf build.
>> As far as I can see this would have the same effect as hardcoding
>> "set(QL_HAVE_CONFIG_H ON)" and configuring qldefines.hpp. Apologies if
>> you are not the right person to ask, I somehow connect your name with
>> the recent cmake changes, but maybe there are more contributors behind
>> that.
>>
>> Apart from the code duplication in qldefines.hpp and
>> qldefines.hpp.cfg, I think this approach would also be more
>> transparent: We build QuantLib as a cmake subproject of another cmake
>> project ("ORE"). I recently noticed that this build uses
>> userconfig.hpp instead of config.hpp, because we missed adding
>> "build/QuantLib" as the first include path. Therefore, the original
>> qldefines.hpp instead of the configured one was used and subsequently
>> userconfig.hpp was included since HAVE_CONFIG_H is not defined as a
>> C++ macro by cmake. All this goes through without any error or warning
>> message and led to some confusion on our side. Without configuring
>> qldefines.hpp we would have just gotten an error message that
>> config.hpp isn't found, which obviously is a much better behaviour.
>>
>> For the version file: we now seem to maintain a manual version.hpp
>> (for autoconf or windows builds) and a configured version.hpp that is
>> populated from cmake variables, so we might get different version
>> infos in a windows / autoconf and cmake build.
>>
>> Thanks
>> Peter
>>
>> On Sun, 1 May 2022 at 09:10, Jonathan Sweemer <sw...@gm...> wrote:
>> >
>> > Hi Peter,
>> >
>> > I can’t claim to 100% understand the way that the configuration works on all the various platforms, but as far as I can tell the main reason for still configuring qldefines.hpp in the CMake build is to let the user choose between config.hpp and userconfig.hpp. When the QL_HAVE_CONFIG_H CMake variable is set to true (which it is by default) then qldefines.hpp is configured to include config.hpp, but when it is set to false then qldefines.hpp is configured to include one of the platform-specific files like config.msvc.hpp.
>> >
>> > As far as I understand the history, the various config.*.hpp files along with userconfig.hpp were basically a mechanism for enabling and disabling different features before the CMake build came into existence. With CMake, those features can be turned on and off more easily through build options. On that basis, I’m not sure it makes much sense to expose QL_HAVE_CONFIG_H to “opt-in” to the old way of configuring the build, but again I might be missing some nuance.
>> >
>> > My own opinion is that the CMake build should not overlap with any of the older mechanisms like userconfig.hpp and should instead be implemented in clean, standard, idiomatic CMake as much as possible.
>> >
>> > Not sure if that answers the question but hope it helps.
>> >
>> > Regarding the version, where is the other place it is maintained? I see another version in configure.ac - is this the one you are referring to? Not sure whether autoconf allows for reading a version from a file, but if it does, then perhaps CMake could configure the version from the same file as well.
>> >
>> > Jonathan
>> >
>> >
>> > 2022년 5월 1일 (일) 01:14, Peter Caspers <pca...@gm...>님이 작성:
>> >>
>> >> Hey Luigi, Jonathan,
>> >>
>> >> I didn't follow all the cmake updates in detail so apologies if that
>> >> was discussed before: Is there a reason why cmake configures
>> >> qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
>> >> QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
>> >> the standard qldefines.hpp?
>> >>
>> >> Not directly related: We also configure version.hpp now. I have the
>> >> slight feeling this could do more harm than good, since the version
>> >> info has to be maintained at two places now?
>> >>
>> >> Thanks
>> >> Peter
>> >>
>> >>
>> >> _______________________________________________
>> >> QuantLib-dev mailing list
>> >> Qua...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] cmake configured files

[Jonathan S. <sw...@gm...>]

Hi Peter,

This part of the CMake build settings was added by @pkovacs. I think the
intention may have been to expose QL_HAVE_CONFIG_H as a CMake option with a
default of ON instead of always hardcoding it to ON. But as I mentioned,
there’s no real compelling use case (in my opinion) for setting it to OFF
so I agree that it would be much cleaner to just define HAVE_CONFIG_H in
CMakeLists.txt and thereby eliminate the need for configuring qldefines.hpp.

I actually didn’t realize there were two versions of qldefines.hpp - the
configured one and the non-configured one. That does indeed seem like a
recipe for inconsistency and is reason enough to try and consolidate the
two.

Looks like there’s one other inconsistency between the two qldefines.hpp -
the define for QL_USE_STD_UNIQUE_PTR was only added to the non-configured
one. This should be added to the configured one as well for consistency
until a decision is made about whether to configure or not.

Jonathan


2022년 5월 2일 (월) 03:12, Peter Caspers <pca...@gm...>님이 작성:

> Hi,
>
> thanks. I get how it works. My question is if the code duplication in
> qldefines.hpp / qldefines.hpp.cfg can be avoided by defining the macro
> HAVE_CONFIG_H in the cmake build, just as we do in the autoconf build.
> As far as I can see this would have the same effect as hardcoding
> "set(QL_HAVE_CONFIG_H ON)" and configuring qldefines.hpp. Apologies if
> you are not the right person to ask, I somehow connect your name with
> the recent cmake changes, but maybe there are more contributors behind
> that.
>
> Apart from the code duplication in qldefines.hpp and
> qldefines.hpp.cfg, I think this approach would also be more
> transparent: We build QuantLib as a cmake subproject of another cmake
> project ("ORE"). I recently noticed that this build uses
> userconfig.hpp instead of config.hpp, because we missed adding
> "build/QuantLib" as the first include path. Therefore, the original
> qldefines.hpp instead of the configured one was used and subsequently
> userconfig.hpp was included since HAVE_CONFIG_H is not defined as a
> C++ macro by cmake. All this goes through without any error or warning
> message and led to some confusion on our side. Without configuring
> qldefines.hpp we would have just gotten an error message that
> config.hpp isn't found, which obviously is a much better behaviour.
>
> For the version file: we now seem to maintain a manual version.hpp
> (for autoconf or windows builds) and a configured version.hpp that is
> populated from cmake variables, so we might get different version
> infos in a windows / autoconf and cmake build.
>
> Thanks
> Peter
>
> On Sun, 1 May 2022 at 09:10, Jonathan Sweemer <sw...@gm...> wrote:
> >
> > Hi Peter,
> >
> > I can’t claim to 100% understand the way that the configuration works on
> all the various platforms, but as far as I can tell the main reason for
> still configuring qldefines.hpp in the CMake build is to let the user
> choose between config.hpp and userconfig.hpp. When the QL_HAVE_CONFIG_H
> CMake variable is set to true (which it is by default) then qldefines.hpp
> is configured to include config.hpp, but when it is set to false then
> qldefines.hpp is configured to include one of the platform-specific files
> like config.msvc.hpp.
> >
> > As far as I understand the history, the various config.*.hpp files along
> with userconfig.hpp were basically a mechanism for enabling and disabling
> different features before the CMake build came into existence. With CMake,
> those features can be turned on and off more easily through build options.
> On that basis, I’m not sure it makes much sense to expose QL_HAVE_CONFIG_H
> to “opt-in” to the old way of configuring the build, but again I might be
> missing some nuance.
> >
> > My own opinion is that the CMake build should not overlap with any of
> the older mechanisms like userconfig.hpp and should instead be implemented
> in clean, standard, idiomatic CMake as much as possible.
> >
> > Not sure if that answers the question but hope it helps.
> >
> > Regarding the version, where is the other place it is maintained? I see
> another version in configure.ac - is this the one you are referring to?
> Not sure whether autoconf allows for reading a version from a file, but if
> it does, then perhaps CMake could configure the version from the same file
> as well.
> >
> > Jonathan
> >
> >
> > 2022년 5월 1일 (일) 01:14, Peter Caspers <pca...@gm...>님이 작성:
> >>
> >> Hey Luigi, Jonathan,
> >>
> >> I didn't follow all the cmake updates in detail so apologies if that
> >> was discussed before: Is there a reason why cmake configures
> >> qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
> >> QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
> >> the standard qldefines.hpp?
> >>
> >> Not directly related: We also configure version.hpp now. I have the
> >> slight feeling this could do more harm than good, since the version
> >> info has to be maintained at two places now?
> >>
> >> Thanks
> >> Peter
> >>
> >>
> >> _______________________________________________
> >> QuantLib-dev mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] cmake configured files

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

Hi,

thanks. I get how it works. My question is if the code duplication in
qldefines.hpp / qldefines.hpp.cfg can be avoided by defining the macro
HAVE_CONFIG_H in the cmake build, just as we do in the autoconf build.
As far as I can see this would have the same effect as hardcoding
"set(QL_HAVE_CONFIG_H ON)" and configuring qldefines.hpp. Apologies if
you are not the right person to ask, I somehow connect your name with
the recent cmake changes, but maybe there are more contributors behind
that.

Apart from the code duplication in qldefines.hpp and
qldefines.hpp.cfg, I think this approach would also be more
transparent: We build QuantLib as a cmake subproject of another cmake
project ("ORE"). I recently noticed that this build uses
userconfig.hpp instead of config.hpp, because we missed adding
"build/QuantLib" as the first include path. Therefore, the original
qldefines.hpp instead of the configured one was used and subsequently
userconfig.hpp was included since HAVE_CONFIG_H is not defined as a
C++ macro by cmake. All this goes through without any error or warning
message and led to some confusion on our side. Without configuring
qldefines.hpp we would have just gotten an error message that
config.hpp isn't found, which obviously is a much better behaviour.

For the version file: we now seem to maintain a manual version.hpp
(for autoconf or windows builds) and a configured version.hpp that is
populated from cmake variables, so we might get different version
infos in a windows / autoconf and cmake build.

Thanks
Peter

On Sun, 1 May 2022 at 09:10, Jonathan Sweemer <sw...@gm...> wrote:
>
> Hi Peter,
>
> I can’t claim to 100% understand the way that the configuration works on all the various platforms, but as far as I can tell the main reason for still configuring qldefines.hpp in the CMake build is to let the user choose between config.hpp and userconfig.hpp. When the QL_HAVE_CONFIG_H CMake variable is set to true (which it is by default) then qldefines.hpp is configured to include config.hpp, but when it is set to false then qldefines.hpp is configured to include one of the platform-specific files like config.msvc.hpp.
>
> As far as I understand the history, the various config.*.hpp files along with userconfig.hpp were basically a mechanism for enabling and disabling different features before the CMake build came into existence. With CMake, those features can be turned on and off more easily through build options. On that basis, I’m not sure it makes much sense to expose QL_HAVE_CONFIG_H to “opt-in” to the old way of configuring the build, but again I might be missing some nuance.
>
> My own opinion is that the CMake build should not overlap with any of the older mechanisms like userconfig.hpp and should instead be implemented in clean, standard, idiomatic CMake as much as possible.
>
> Not sure if that answers the question but hope it helps.
>
> Regarding the version, where is the other place it is maintained? I see another version in configure.ac - is this the one you are referring to? Not sure whether autoconf allows for reading a version from a file, but if it does, then perhaps CMake could configure the version from the same file as well.
>
> Jonathan
>
>
> 2022년 5월 1일 (일) 01:14, Peter Caspers <pca...@gm...>님이 작성:
>>
>> Hey Luigi, Jonathan,
>>
>> I didn't follow all the cmake updates in detail so apologies if that
>> was discussed before: Is there a reason why cmake configures
>> qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
>> QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
>> the standard qldefines.hpp?
>>
>> Not directly related: We also configure version.hpp now. I have the
>> slight feeling this could do more harm than good, since the version
>> info has to be maintained at two places now?
>>
>> Thanks
>> Peter
>>
>>
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] cmake configured files

[Jonathan S. <sw...@gm...>]

Hi Peter,

I can’t claim to 100% understand the way that the configuration works on
all the various platforms, but as far as I can tell the main reason for
still configuring qldefines.hpp in the CMake build is to let the user
choose between config.hpp and userconfig.hpp. When the QL_HAVE_CONFIG_H
CMake variable is set to true (which it is by default) then qldefines.hpp
is configured to include config.hpp, but when it is set to false then
qldefines.hpp is configured to include one of the platform-specific files
like config.msvc.hpp.

As far as I understand the history, the various config.*.hpp files along
with userconfig.hpp were basically a mechanism for enabling and disabling
different features before the CMake build came into existence. With CMake,
those features can be turned on and off more easily through build options.
On that basis, I’m not sure it makes much sense to expose QL_HAVE_CONFIG_H
to “opt-in” to the old way of configuring the build, but again I might be
missing some nuance.

My own opinion is that the CMake build should not overlap with any of the
older mechanisms like userconfig.hpp and should instead be implemented in
clean, standard, idiomatic CMake as much as possible.

Not sure if that answers the question but hope it helps.

Regarding the version, where is the other place it is maintained? I see
another version in configure.ac - is this the one you are referring to? Not
sure whether autoconf allows for reading a version from a file, but if it
does, then perhaps CMake could configure the version from the same file as
well.

Jonathan


2022년 5월 1일 (일) 01:14, Peter Caspers <pca...@gm...>님이 작성:

> Hey Luigi, Jonathan,
>
> I didn't follow all the cmake updates in detail so apologies if that
> was discussed before: Is there a reason why cmake configures
> qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
> QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
> the standard qldefines.hpp?
>
> Not directly related: We also configure version.hpp now. I have the
> slight feeling this could do more harm than good, since the version
> info has to be maintained at two places now?
>
> Thanks
> Peter
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] cmake configured files

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

Hey Luigi, Jonathan,

I didn't follow all the cmake updates in detail so apologies if that
was discussed before: Is there a reason why cmake configures
qldefines.hpp? Couldn't we just define HAVE_CONFIG_H instead of
QL_CONFIG_H in the top CMakeLists.txt and it would "just work" with
the standard qldefines.hpp?

Not directly related: We also configure version.hpp now. I have the
slight feeling this could do more harm than good, since the version
info has to be maintained at two places now?

Thanks
Peter

[Quantlib-dev] QuantLib 1.26 released

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

QuantLib 1.26 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

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

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

Re: [Quantlib-dev] Interested in contributing code to the project, but don’t know where to start

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

Thanks, Jonathan — just a note: the disclaimer part in the dev intro is
outdated (we're using <https://cla-assistant.io/> now which is
integrated with pull requests) so you can disregard that part.  I should
probably remove it.

Luigi


On Thu, Feb 24, 2022 at 2:44 PM Jonathan Sweemer <sw...@gm...> wrote:

> Hi Mike,
>
> Welcome to QuantLib! Here is the developer introduction in case you
> haven't seen it yet:
>
> https://www.quantlib.org/newdeveloper.shtml
>
> There is always a lot to be done in QuantLib so your contributions will be
> welcome. Feel free to take a look at the open issues marked "help wanted"
> and open a pull request for one that you think you can handle.
>
>
> https://github.com/lballabio/QuantLib/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22
>
> For questions about an issue, you can ask directly on github and somebody
> will answer you there.
>
> Jonathan
>
> On Thu, Feb 24, 2022 at 10:44 AM Phạm Như Mạnh <pnm...@gm...> wrote:
>
>> Hi,
>>
>> My name is Mike. I’m currently an Software Engineer Intern at Service
>> Now, and a computer science major at Worcester Polytechnic Institute, US.
>>
>> I’ve recently developed an interest in financial careers and thus want to
>> explore more and experience hands-on coding with programming financial
>> product like quantlib. A little programming background about me: I am
>> fairly well-versed in basic C++ concepts such as basic syntax, object
>> oriented programming concepts, STL functions, data structures,  algorithms,
>> and memory management. I have also taken practical math classes such as
>> statistics and probability.
>>
>> I’d like to contribute to the codebase of the project, but I do not know
>> where to start, since the project was already developed extensively. If
>> possible, I’m looking for a specific feature where I could start
>> researching and building towards on.
>>
>> Thank you for your time and consideration. I look forward to hearing from
>> you soon.
>>
>> Best,
>> Mike,
>> Mike Pham
>>
>>
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Interested in contributing code to the project, but don’t know where to start

[Jonathan S. <sw...@gm...>]

Hi Mike,

Welcome to QuantLib! Here is the developer introduction in case you
haven't seen it yet:

https://www.quantlib.org/newdeveloper.shtml

There is always a lot to be done in QuantLib so your contributions will be
welcome. Feel free to take a look at the open issues marked "help wanted"
and open a pull request for one that you think you can handle.

https://github.com/lballabio/QuantLib/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22

For questions about an issue, you can ask directly on github and somebody
will answer you there.

Jonathan

On Thu, Feb 24, 2022 at 10:44 AM Phạm Như Mạnh <pnm...@gm...> wrote:

> Hi,
>
> My name is Mike. I’m currently an Software Engineer Intern at Service Now,
> and a computer science major at Worcester Polytechnic Institute, US.
>
> I’ve recently developed an interest in financial careers and thus want to
> explore more and experience hands-on coding with programming financial
> product like quantlib. A little programming background about me: I am
> fairly well-versed in basic C++ concepts such as basic syntax, object
> oriented programming concepts, STL functions, data structures,  algorithms,
> and memory management. I have also taken practical math classes such as
> statistics and probability.
>
> I’d like to contribute to the codebase of the project, but I do not know
> where to start, since the project was already developed extensively. If
> possible, I’m looking for a specific feature where I could start
> researching and building towards on.
>
> Thank you for your time and consideration. I look forward to hearing from
> you soon.
>
> Best,
> Mike,
> Mike Pham
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Interested in contributing code to the project, but don’t know where to start

[Phạm N. M. <pnm...@gm...>]

Hi,

My name is Mike. I’m currently an Software Engineer Intern at Service Now,
and a computer science major at Worcester Polytechnic Institute, US.

I’ve recently developed an interest in financial careers and thus want to
explore more and experience hands-on coding with programming financial
product like quantlib. A little programming background about me: I am
fairly well-versed in basic C++ concepts such as basic syntax, object
oriented programming concepts, STL functions, data structures,  algorithms,
and memory management. I have also taken practical math classes such as
statistics and probability.

I’d like to contribute to the codebase of the project, but I do not know
where to start, since the project was already developed extensively. If
possible, I’m looking for a specific feature where I could start
researching and building towards on.

Thank you for your time and consideration. I look forward to hearing from
you soon.

Best,
Mike,
Mike Pham

Re: [Quantlib-dev] Option pricing BARONE-ADESI/WHALEY and negative discount rate

[Lawrence S. <law...@gm...>]

Thanks. I'll check if there is a work around.

The driver is speed. My metrics show this method is 500 times faster than
all binomial methods. For pricing 800k options with basic greeks and
shocks, the difference is minutes versus day.

On Thu, Jan 20, 2022, 5:05 AM YaoBin Kuo, <yp...@gm...> wrote:

>
> As I rember, Barone-Adesi/Whaley Paper，there is a quadratic equation,
> the  discriminant is (N-1)^2 + 4M/K
> where N = 2b/sigma^2, M = 2r/sigma^2, K = 1 - e^(-rT)
> so when (N-1)^2 + 4M/K < 0, the method fail
> So use binomial tree method.
>
>
> Lawrence Sum <law...@gm...> 於 2022年1月17日 週一 下午10:45寫道：
>
>> Hi,
>>
>> I am still using QuantLib 1.22/Windows and testing negative
>> discount rates for all option pricing methods. I noticed if the discount
>> rate is negative (I used -1.2%) and Barone-Adesi/Whaley will crash (forward
>> + displacement (-3.875e+14 + 0) must be positive). All other methods seemed
>> to produce reasonable prices. If the rate is exactly zero there is no
>> crash. Is this an issue to fix or this is expected?
>>
>> I cross-tested negative rate for  Barone-Adesi/Whaley using matlab/fin
>> toolkit and it worked there.
>>
>> Thanks
>> Lawrence Sum
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>

Re: [Quantlib-dev] Option pricing BARONE-ADESI/WHALEY and negative discount rate

[YaoBin K. <yp...@gm...>]

As I rember, Barone-Adesi/Whaley Paper，there is a quadratic equation,
the  discriminant is (N-1)^2 + 4M/K
where N = 2b/sigma^2, M = 2r/sigma^2, K = 1 - e^(-rT)
so when (N-1)^2 + 4M/K < 0, the method fail
So use binomial tree method.


Lawrence Sum <law...@gm...> 於 2022年1月17日 週一 下午10:45寫道：

> Hi,
>
> I am still using QuantLib 1.22/Windows and testing negative discount rates
> for all option pricing methods. I noticed if the discount rate is negative
> (I used -1.2%) and Barone-Adesi/Whaley will crash (forward + displacement
> (-3.875e+14 + 0) must be positive). All other methods seemed to produce
> reasonable prices. If the rate is exactly zero there is no crash. Is this
> an issue to fix or this is expected?
>
> I cross-tested negative rate for  Barone-Adesi/Whaley using matlab/fin
> toolkit and it worked there.
>
> Thanks
> Lawrence Sum
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Option pricing BARONE-ADESI/WHALEY and negative discount rate

[Jonathan S. <sw...@gm...>]

I was able to reproduce this on my computer and it looks like the immediate
technical reason is a divide-by-nearly-zero error[1].

I would recommend opening an issue and/or a pull request on github.

[1]
https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/vanilla/baroneadesiwhaleyengine.cpp#L115
.

On Tue, Jan 18, 2022 at 10:47 PM Lawrence Sum <law...@gm...>
wrote:

> Hi Jonathan
>
> The actual code is very complicated and quite massive. But I can reproduce
> the problem via the EquityOption Quantlib sample as follows:
>
> Essentially to reproduce the problem, just set riskfree rate to -0.012.
> And here is what I got:
>
> Option type = Put
> Maturity = May 17th, 1999
> Underlying price = 36
> Strike = 40
> *Risk-free interest rate = -1.200000 %*
> Dividend yield = 0.000000 %
> Volatility = 20.000000 %
>
>
> Method                             European      Bermudan      American
> August 20th, 1998
> November 20th, 1998
> February 20th, 1999
> May 20th, 1999
> Black-Scholes                      5.781564      N/A           N/A
> Black Vasicek Model                5.274950      N/A           N/A
> Heston semi-analytic               5.781563      N/A           N/A
> Bates semi-analytic                5.781563      N/A           N/A
> forward + displacement (-3.875e+14 + 0) must be positive
>
> On Tue, Jan 18, 2022 at 7:27 AM Jonathan Sweemer <sw...@gm...>
> wrote:
>
>> Hi Lawrence,
>>
>> Are you able to share a snippet of the source code that crashes for you?
>>
>> On Mon, Jan 17, 2022 at 11:45 PM Lawrence Sum <law...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> I am still using QuantLib 1.22/Windows and testing negative
>>> discount rates for all option pricing methods. I noticed if the discount
>>> rate is negative (I used -1.2%) and Barone-Adesi/Whaley will crash (forward
>>> + displacement (-3.875e+14 + 0) must be positive). All other methods seemed
>>> to produce reasonable prices. If the rate is exactly zero there is no
>>> crash. Is this an issue to fix or this is expected?
>>>
>>> I cross-tested negative rate for  Barone-Adesi/Whaley using matlab/fin
>>> toolkit and it worked there.
>>>
>>> Thanks
>>> Lawrence Sum
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>

Re: [Quantlib-dev] Option pricing BARONE-ADESI/WHALEY and negative discount rate

[Lawrence S. <law...@gm...>]

Hi Jonathan

The actual code is very complicated and quite massive. But I can reproduce
the problem via the EquityOption Quantlib sample as follows:

Essentially to reproduce the problem, just set riskfree rate to -0.012. And
here is what I got:

Option type = Put
Maturity = May 17th, 1999
Underlying price = 36
Strike = 40
*Risk-free interest rate = -1.200000 %*
Dividend yield = 0.000000 %
Volatility = 20.000000 %


Method                             European      Bermudan      American
August 20th, 1998
November 20th, 1998
February 20th, 1999
May 20th, 1999
Black-Scholes                      5.781564      N/A           N/A
Black Vasicek Model                5.274950      N/A           N/A
Heston semi-analytic               5.781563      N/A           N/A
Bates semi-analytic                5.781563      N/A           N/A
forward + displacement (-3.875e+14 + 0) must be positive

On Tue, Jan 18, 2022 at 7:27 AM Jonathan Sweemer <sw...@gm...> wrote:

> Hi Lawrence,
>
> Are you able to share a snippet of the source code that crashes for you?
>
> On Mon, Jan 17, 2022 at 11:45 PM Lawrence Sum <law...@gm...>
> wrote:
>
>> Hi,
>>
>> I am still using QuantLib 1.22/Windows and testing negative
>> discount rates for all option pricing methods. I noticed if the discount
>> rate is negative (I used -1.2%) and Barone-Adesi/Whaley will crash (forward
>> + displacement (-3.875e+14 + 0) must be positive). All other methods seemed
>> to produce reasonable prices. If the rate is exactly zero there is no
>> crash. Is this an issue to fix or this is expected?
>>
>> I cross-tested negative rate for  Barone-Adesi/Whaley using matlab/fin
>> toolkit and it worked there.
>>
>> Thanks
>> Lawrence Sum
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>