quantlib-dev — Discussion of QuantLib development

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

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

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
>

[Quantlib-dev] QuantLib 1.25 released

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

QuantLib 1.25 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>.

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

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

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

Re: [Quantlib-dev] setup Quantlib CMake project using qt creator (Windows)

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

Hi Mohammad,

I’ve never used Qt Creator before but a google search led me to this page:

https://doc.qt.io/qt-5/cmake-get-started.html

As for QuantLib, you can find an unofficial sample CMakeLists.txt file here:

https://github.com/sweemer/quantlib-vcpkg-example/blob/025760be5befe150274ce7369066d581ffb50cf5/CMakeLists.txt

You will have to update the include directories and link directories to
point to the proper installation location on your computer.

By the way you should use the quantlib-users emailing list for questions on
usage, as this email list is for development of quantlib itself.


2021년 12월 22일 (수) 00:33, Mohammad Shoja-talab <msh...@gm...>님이 작성:

> Hi,
>
> I'm new to Qt Creator and CMake, looking at the quantlib it seems that it
> now supports CMake, can someone point me to some help/doc/etc. how to set
> up quantlib (or any other project that supports CMake for that matter)
> build/run using qt creator on Windows please?
>
>
> thanks
> --
> Mohammad Shojatalab
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] setup Quantlib CMake project using qt creator (Windows)

[Mohammad Shoja-t. <msh...@gm...>]

Hi,

I'm new to Qt Creator and CMake, looking at the quantlib it seems that it
now supports CMake, can someone point me to some help/doc/etc. how to set
up quantlib (or any other project that supports CMake for that matter)
build/run using qt creator on Windows please?


thanks
-- 
Mohammad Shojatalab

Re: [Quantlib-dev] Obsolete constructor call in HistoricalForwardRatesAnalysis

[Francois B. <ig...@gm...>]

Thanks Luigi,

I submitted a PR to fix this at
https://github.com/lballabio/QuantLib/pull/1267 .

Francois Botha


On Thu, 16 Dec 2021 at 13:44, Luigi Ballabio <lui...@gm...>
wrote:

> It might be that it's a template which is never actually instantiated.
> It's probably not used in any tests.
>
> Luigi
>
>
> On Thu, Dec 16, 2021 at 12:19 PM Francois Botha <ig...@gm...> wrote:
>
>> Hi,
>>
>> After a recent query about QuantlibXL
>> <https://sourceforge.net/p/quantlib/mailman/message/37401063/>, I
>> decided to try to build it myself against Quantlib 1.23. However, before I
>> could even reach the relevant part of the query I noticed something else
>> that confuses me.
>>
>> If I build Quantlib on its own (+ its test suite, but excluding
>> examples), the build completes without compile time errors.
>>
>> But when I link QuantlibXL to Quantlib v1.23 then I get a compile time
>> error at
>>
>> https://github.com/lballabio/QuantLib/blob/73e39d104693a959ecc38fa3d0c6ee7875cd2fc4/ql/models/marketmodels/historicalforwardratesanalysis.hpp#L134
>>
>> You'll notice the line passes the Real accuracy parameter that has
>> recently moved to the Bootstrap object. So the compile time error makes
>> sense to me. However, I'm confused as to why the build passes when I'm
>> building Quantlib on its own, as historicalforwardratesanalysis.hpp is part
>> of the Quantlib project and I expected the compile error to occur there
>> too.
>>
>> Is this a C++ peculiarity where, if nothing links to the class, it is
>> optimised out and not actually compiled?
>>
>> thanks
>> Francois Botha
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>

Re: [Quantlib-dev] Obsolete constructor call in HistoricalForwardRatesAnalysis

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

It might be that it's a template which is never actually instantiated.
It's probably not used in any tests.

Luigi


On Thu, Dec 16, 2021 at 12:19 PM Francois Botha <ig...@gm...> wrote:

> Hi,
>
> After a recent query about QuantlibXL
> <https://sourceforge.net/p/quantlib/mailman/message/37401063/>, I decided
> to try to build it myself against Quantlib 1.23. However, before I could
> even reach the relevant part of the query I noticed something else that
> confuses me.
>
> If I build Quantlib on its own (+ its test suite, but excluding examples),
> the build completes without compile time errors.
>
> But when I link QuantlibXL to Quantlib v1.23 then I get a compile time
> error at
>
> https://github.com/lballabio/QuantLib/blob/73e39d104693a959ecc38fa3d0c6ee7875cd2fc4/ql/models/marketmodels/historicalforwardratesanalysis.hpp#L134
>
> You'll notice the line passes the Real accuracy parameter that has
> recently moved to the Bootstrap object. So the compile time error makes
> sense to me. However, I'm confused as to why the build passes when I'm
> building Quantlib on its own, as historicalforwardratesanalysis.hpp is part
> of the Quantlib project and I expected the compile error to occur there
> too.
>
> Is this a C++ peculiarity where, if nothing links to the class, it is
> optimised out and not actually compiled?
>
> thanks
> Francois Botha
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Obsolete constructor call in HistoricalForwardRatesAnalysis

[Francois B. <ig...@gm...>]

Hi,

After a recent query about QuantlibXL
<https://sourceforge.net/p/quantlib/mailman/message/37401063/>, I decided
to try to build it myself against Quantlib 1.23. However, before I could
even reach the relevant part of the query I noticed something else that
confuses me.

If I build Quantlib on its own (+ its test suite, but excluding examples),
the build completes without compile time errors.

But when I link QuantlibXL to Quantlib v1.23 then I get a compile time
error at
https://github.com/lballabio/QuantLib/blob/73e39d104693a959ecc38fa3d0c6ee7875cd2fc4/ql/models/marketmodels/historicalforwardratesanalysis.hpp#L134

You'll notice the line passes the Real accuracy parameter that has recently
moved to the Bootstrap object. So the compile time error makes sense to me.
However, I'm confused as to why the build passes when I'm building Quantlib
on its own, as historicalforwardratesanalysis.hpp is part of the Quantlib
project and I expected the compile error to occur there too.

Is this a C++ peculiarity where, if nothing links to the class, it is
optimised out and not actually compiled?

thanks
Francois Botha

Re: [Quantlib-dev] Possible sub-project for calendaring ?

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

Hello Dirk,
    I must say, seeing you take on project after project gives me hope that
I'll have some more time when the kids are all grown up :)

Luigi



On Fri, Oct 29, 2021 at 3:46 PM Dirk Eddelbuettel <ed...@de...> wrote:

>
> Hi Francois,
>
> On 29 October 2021 at 14:53, Francois Botha wrote:
> | Thanks for this. I think this is a great idea. In fact, in-house I built
> | something similar in C# based on a subset of the classes in QLNet.
>
> Nice to know too!
>
> | Is your idea that QuantLib links to this "QLCal" project? I'm  just
>
> Link as in code, or link as in http URL on website?
>
> QuantLib is also of course the 'mothership' and retains all code. I am
> simply
> thinking it may be useful to have a (clearly related) 'derivative' project.
>
> I would suggest that the code bases remain separate for simplicity, at
> least
> initially, but 'not too separate' as we saw with Quantuccia that updates
> may
> not happen if they take effort.  'QlCal' as it presently stands is just my
> (current) RcppQuantuccia snapshot which has copies. As just how I have
> updated the Debian build of QuantLib (and whatever changes RQuantLib
> needed)
> for twenty years now, I can similarly refresh the copies of QuantLib
> calendaring code in this new project to keep it current.
>
> But I figured I should bring it up here as QuantLib-at-large has ownership
> of
> these files (just like you do for Botswana.{cpp,hpp}) and might want to be
> involved.  One other idea I had is to maybe try in QlCal to remove the
> Boost
> dependency further. (I looked into `bcp` and find the minimal set of Boost
> headers to create a truly dependency-free source tar.gz, it is still too
> much.)  Using Hinnant's Date class instead of Boost's may be an idea too.
>
> | wondering about the maintenance of public holiday rules and especially ad
> | hoc public holidays (like 1 Nov 2021 was recently declared a special
> public
> | holiday for election/voting purposes). If both projects have to be
> | maintained separately there is of course a risk that they diverge, which
> | could cause some confusion among users.
>
> That is precisely why I rebooted this. I will try to keep it current on an
> ongoing basis, at least in RcppQuantuccia and possibly in extensions. If I
> find time I will produce a small standalone executable one could call from
> scripts and pipelines.  It sounds like you have something you could base on
> this if we went the Swig route for interfaces (or created a C language FFI
> around the C++ layer for easier C-level FFI).
>
> So in short, I just tossed a flare in the sky ("hey, I did this") and I am
> glad to hear from you about both a similar, local initiative ("hey, I am
> not
> crazy, there is demand") and the reply.  So let's talk and see if there is
> something to be done together.  I mostly wanted folks to be aware and have
> the option of being involved.
>
> Dirk
>
>
> | thanks
> | Francois Botha
> |
> |
> | On Tue, 26 Oct 2021 at 21:39, Dirk Eddelbuettel <ed...@de...> wrote:
> |
> | >
> | > So a few years ago Peter had this nice idea and trial balloon of
> | > Quantuccia.
> | > I jumped on it as the 20 years (!!!) with RQuantLib have clearly shown
> that
> | > expecting systems to have the QuantLib library installed is (still) a
> | > hurdle.
> | > Quantuccia overcame that by being header-only and depending only on
> | > header-only Boost. Very nice indeed. So I built RcppQuantuccia around
> it.
> | >
> | > But copies are of course extra effort to maintain, especially when you
> have
> | > to do a slight modification in each file (in essence: concat hpp and
> cpp
> | > into
> | > one hpp, prefix each function with inline; a tool _could_ do this). So
> my
> | > RcppQuantuccia got stale as Quantuccia got stale.
> | >
> | > The recent QuantLib 1.24 updates, new (US) calendaring, and user
> requests
> | > for
> | > extra calendars (that I was not yet exporting) made me take another
> look.
> | > And
> | > consequently I did a few small things over a couple of days:
> | >
> | >  - update Quantuccia to QuantLib 1.24, but also remove everything from
> | >    Quantuccia that was not used in RcppQuantuccia
> | >  - undo the header-only internal design for the R package and just
> list the
> | >    two or three dozen files explicitly as a Make dependency
> | >  - effectively I created a 'QuantLib Calendaring' sublibrary
> | >
> | > This now exists, and is current to 1.24.
> | >
> | > And I think that this has merit, possibly beyond RcppQuantuccia.  The
> | > current
> | > master branch of github.com/eddelbuettel/rcppquantuccia contains it,
> take
> | > a
> | > look.  I needed to make minimal changes to a few files I need to
> document,
> | > in
> | > essence a) comment out the #pragam statements as CRAN will not let use
> them
> | > and b) include the errrors.hpp header in a handful of files.
> | >
> | > So five paragraphs in, here is my question: Would anybody else be
> | > interested
> | > in a 'QuantLib Calender Lite' library?
> | >
> | > One could possibly wrap Python bindings around (though I am unsure
> what to
> | > do
> | > about Boost header and Python), and/or use Swig, and I think it may
> make
> | > sense to turn this into a small standalone cmdline app al
> | >
> | >     qlcal holidays --calendar UnitedStates --from 2021-10-01 --to
> | > 2021-10-31
> | >
> | > I poked a little at GitHub and qlcal was open to I 'parked this' as an
> org
> | > if
> | > we wanted to put it there.
> | >
> | > Thoughts? Anybody else up for this?
> | >
> | > Dirk
> | >
> | > --
> | > https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
> | >
> | >
> | > _______________________________________________
> | > QuantLib-dev mailing list
> | > Qua...@li...
> | > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> | >
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Possible sub-project for calendaring ?

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

Hi Francois,

On 29 October 2021 at 14:53, Francois Botha wrote:
| Thanks for this. I think this is a great idea. In fact, in-house I built
| something similar in C# based on a subset of the classes in QLNet.

Nice to know too!

| Is your idea that QuantLib links to this "QLCal" project? I'm  just

Link as in code, or link as in http URL on website?

QuantLib is also of course the 'mothership' and retains all code. I am simply
thinking it may be useful to have a (clearly related) 'derivative' project.

I would suggest that the code bases remain separate for simplicity, at least
initially, but 'not too separate' as we saw with Quantuccia that updates may
not happen if they take effort.  'QlCal' as it presently stands is just my
(current) RcppQuantuccia snapshot which has copies. As just how I have
updated the Debian build of QuantLib (and whatever changes RQuantLib needed)
for twenty years now, I can similarly refresh the copies of QuantLib
calendaring code in this new project to keep it current.

But I figured I should bring it up here as QuantLib-at-large has ownership of
these files (just like you do for Botswana.{cpp,hpp}) and might want to be
involved.  One other idea I had is to maybe try in QlCal to remove the Boost
dependency further. (I looked into `bcp` and find the minimal set of Boost
headers to create a truly dependency-free source tar.gz, it is still too
much.)  Using Hinnant's Date class instead of Boost's may be an idea too.

| wondering about the maintenance of public holiday rules and especially ad
| hoc public holidays (like 1 Nov 2021 was recently declared a special public
| holiday for election/voting purposes). If both projects have to be
| maintained separately there is of course a risk that they diverge, which
| could cause some confusion among users.

That is precisely why I rebooted this. I will try to keep it current on an
ongoing basis, at least in RcppQuantuccia and possibly in extensions. If I
find time I will produce a small standalone executable one could call from
scripts and pipelines.  It sounds like you have something you could base on
this if we went the Swig route for interfaces (or created a C language FFI
around the C++ layer for easier C-level FFI).  

So in short, I just tossed a flare in the sky ("hey, I did this") and I am
glad to hear from you about both a similar, local initiative ("hey, I am not
crazy, there is demand") and the reply.  So let's talk and see if there is
something to be done together.  I mostly wanted folks to be aware and have
the option of being involved.

Dirk


| thanks
| Francois Botha
| 
| 
| On Tue, 26 Oct 2021 at 21:39, Dirk Eddelbuettel <ed...@de...> wrote:
| 
| >
| > So a few years ago Peter had this nice idea and trial balloon of
| > Quantuccia.
| > I jumped on it as the 20 years (!!!) with RQuantLib have clearly shown that
| > expecting systems to have the QuantLib library installed is (still) a
| > hurdle.
| > Quantuccia overcame that by being header-only and depending only on
| > header-only Boost. Very nice indeed. So I built RcppQuantuccia around it.
| >
| > But copies are of course extra effort to maintain, especially when you have
| > to do a slight modification in each file (in essence: concat hpp and cpp
| > into
| > one hpp, prefix each function with inline; a tool _could_ do this). So my
| > RcppQuantuccia got stale as Quantuccia got stale.
| >
| > The recent QuantLib 1.24 updates, new (US) calendaring, and user requests
| > for
| > extra calendars (that I was not yet exporting) made me take another look.
| > And
| > consequently I did a few small things over a couple of days:
| >
| >  - update Quantuccia to QuantLib 1.24, but also remove everything from
| >    Quantuccia that was not used in RcppQuantuccia
| >  - undo the header-only internal design for the R package and just list the
| >    two or three dozen files explicitly as a Make dependency
| >  - effectively I created a 'QuantLib Calendaring' sublibrary
| >
| > This now exists, and is current to 1.24.
| >
| > And I think that this has merit, possibly beyond RcppQuantuccia.  The
| > current
| > master branch of github.com/eddelbuettel/rcppquantuccia contains it, take
| > a
| > look.  I needed to make minimal changes to a few files I need to document,
| > in
| > essence a) comment out the #pragam statements as CRAN will not let use them
| > and b) include the errrors.hpp header in a handful of files.
| >
| > So five paragraphs in, here is my question: Would anybody else be
| > interested
| > in a 'QuantLib Calender Lite' library?
| >
| > One could possibly wrap Python bindings around (though I am unsure what to
| > do
| > about Boost header and Python), and/or use Swig, and I think it may make
| > sense to turn this into a small standalone cmdline app al
| >
| >     qlcal holidays --calendar UnitedStates --from 2021-10-01 --to
| > 2021-10-31
| >
| > I poked a little at GitHub and qlcal was open to I 'parked this' as an org
| > if
| > we wanted to put it there.
| >
| > Thoughts? Anybody else up for this?
| >
| > Dirk
| >
| > --
| > https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
| >
| >
| > _______________________________________________
| > QuantLib-dev mailing list
| > Qua...@li...
| > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| >

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-dev] Possible sub-project for calendaring ?

[Francois B. <ig...@gm...>]

Hi Dirk,

Thanks for this. I think this is a great idea. In fact, in-house I built
something similar in C# based on a subset of the classes in QLNet.

Is your idea that QuantLib links to this "QLCal" project? I'm  just
wondering about the maintenance of public holiday rules and especially ad
hoc public holidays (like 1 Nov 2021 was recently declared a special public
holiday for election/voting purposes). If both projects have to be
maintained separately there is of course a risk that they diverge, which
could cause some confusion among users.

thanks
Francois Botha


On Tue, 26 Oct 2021 at 21:39, Dirk Eddelbuettel <ed...@de...> wrote:

>
> So a few years ago Peter had this nice idea and trial balloon of
> Quantuccia.
> I jumped on it as the 20 years (!!!) with RQuantLib have clearly shown that
> expecting systems to have the QuantLib library installed is (still) a
> hurdle.
> Quantuccia overcame that by being header-only and depending only on
> header-only Boost. Very nice indeed. So I built RcppQuantuccia around it.
>
> But copies are of course extra effort to maintain, especially when you have
> to do a slight modification in each file (in essence: concat hpp and cpp
> into
> one hpp, prefix each function with inline; a tool _could_ do this). So my
> RcppQuantuccia got stale as Quantuccia got stale.
>
> The recent QuantLib 1.24 updates, new (US) calendaring, and user requests
> for
> extra calendars (that I was not yet exporting) made me take another look.
> And
> consequently I did a few small things over a couple of days:
>
>  - update Quantuccia to QuantLib 1.24, but also remove everything from
>    Quantuccia that was not used in RcppQuantuccia
>  - undo the header-only internal design for the R package and just list the
>    two or three dozen files explicitly as a Make dependency
>  - effectively I created a 'QuantLib Calendaring' sublibrary
>
> This now exists, and is current to 1.24.
>
> And I think that this has merit, possibly beyond RcppQuantuccia.  The
> current
> master branch of github.com/eddelbuettel/rcppquantuccia contains it, take
> a
> look.  I needed to make minimal changes to a few files I need to document,
> in
> essence a) comment out the #pragam statements as CRAN will not let use them
> and b) include the errrors.hpp header in a handful of files.
>
> So five paragraphs in, here is my question: Would anybody else be
> interested
> in a 'QuantLib Calender Lite' library?
>
> One could possibly wrap Python bindings around (though I am unsure what to
> do
> about Boost header and Python), and/or use Swig, and I think it may make
> sense to turn this into a small standalone cmdline app al
>
>     qlcal holidays --calendar UnitedStates --from 2021-10-01 --to
> 2021-10-31
>
> I poked a little at GitHub and qlcal was open to I 'parked this' as an org
> if
> we wanted to put it there.
>
> Thoughts? Anybody else up for this?
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Possible sub-project for calendaring ?

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

So a few years ago Peter had this nice idea and trial balloon of Quantuccia.
I jumped on it as the 20 years (!!!) with RQuantLib have clearly shown that
expecting systems to have the QuantLib library installed is (still) a hurdle.
Quantuccia overcame that by being header-only and depending only on
header-only Boost. Very nice indeed. So I built RcppQuantuccia around it.

But copies are of course extra effort to maintain, especially when you have
to do a slight modification in each file (in essence: concat hpp and cpp into
one hpp, prefix each function with inline; a tool _could_ do this). So my
RcppQuantuccia got stale as Quantuccia got stale.

The recent QuantLib 1.24 updates, new (US) calendaring, and user requests for
extra calendars (that I was not yet exporting) made me take another look. And
consequently I did a few small things over a couple of days:

 - update Quantuccia to QuantLib 1.24, but also remove everything from
   Quantuccia that was not used in RcppQuantuccia
 - undo the header-only internal design for the R package and just list the
   two or three dozen files explicitly as a Make dependency
 - effectively I created a 'QuantLib Calendaring' sublibrary

This now exists, and is current to 1.24.

And I think that this has merit, possibly beyond RcppQuantuccia.  The current
master branch of github.com/eddelbuettel/rcppquantuccia contains it, take a
look.  I needed to make minimal changes to a few files I need to document, in
essence a) comment out the #pragam statements as CRAN will not let use them
and b) include the errrors.hpp header in a handful of files.

So five paragraphs in, here is my question: Would anybody else be interested
in a 'QuantLib Calender Lite' library?

One could possibly wrap Python bindings around (though I am unsure what to do
about Boost header and Python), and/or use Swig, and I think it may make
sense to turn this into a small standalone cmdline app al

    qlcal holidays --calendar UnitedStates --from 2021-10-01 --to 2021-10-31

I poked a little at GitHub and qlcal was open to I 'parked this' as an org if
we wanted to put it there.

Thoughts? Anybody else up for this?

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-dev] QuantLib 1.24 released

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

QuantLib 1.24 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] Porting Guide

[Bryte M. <bry...@qn...>]

SWIG formerly supported  Common Lisp  through it's Foreign Function 
Interface feature. It formerly supported Allegro Lisp implementation, 
CLISP Implementation and the CFFI Library.

What I do have  in mind alternatively is to manually write the bindings 
using the more portable CFFI library the old faction way, though this 
seems like a rather longer path to my original goal, however this 
implies I would have a lot more grip over how common-lisp wrapper code 
is crafted (probably working around implementation specific limitations 
for each type  of compiler or interpreter that supports CFFI Library 
where possible). Using the CFFI library have the advantage of keeping 
portability in strict check.

I think the current SWIG bindings would point me in a general direction 
of breaking the process into smaller steps, going one module at a time......


On 13/10/2021 08:25, Luigi Ballabio wrote:
> Hello Bryte,
>     if you want to use SWIG (does it support Common Lisp?), yes, you 
> can start from the existing SWIG bindings, but be aware that they 
> require some features like automatic support for shared_ptr, and SWIG 
> doesn't provide it for all the languages it supports, so you'll have 
> to check that.
>
> If you want a pure Common Lisp port, there's no guide — and if there 
> were one, it would probably get in the way of writing idiomatic CL, I 
> guess?
>
> What did you have in mind?
>
> Luigi
>
>
> On Mon, Oct 11, 2021 at 12:45 AM Bryte Morio <bry...@qn... 
> <mailto:bry...@qn...>> wrote:
>
>     Is a there a standard guide on  porting Quantlib to other
>     languages. I
>     have trouble finding any existing HOWTOs or general guides. My
>     goal is
>     to port the library to Common-Lisp.
>
>
>
>     _______________________________________________
>     QuantLib-dev mailing list
>     Qua...@li...
>     <mailto:Qua...@li...>
>     https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>     <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>

Re: [Quantlib-dev] Porting Guide

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

Hello Bryte,
    if you want to use SWIG (does it support Common Lisp?), yes, you can
start from the existing SWIG bindings, but be aware that they require some
features like automatic support for shared_ptr, and SWIG doesn't provide it
for all the languages it supports, so you'll have to check that.

If you want a pure Common Lisp port, there's no guide — and if there were
one, it would probably get in the way of writing idiomatic CL, I guess?

What did you have in mind?

Luigi


On Mon, Oct 11, 2021 at 12:45 AM Bryte Morio <bry...@qn...> wrote:

> Is a there a standard guide on  porting Quantlib to other languages. I
> have trouble finding any existing HOWTOs or general guides. My goal is
> to port the library to Common-Lisp.
>
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Porting Guide

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

This might be helpful

https://github.com/lballabio/QuantLib-SWIG



-----Original Message-----
From: Bryte Morio <bry...@qn...> 
Sent: Monday, 11 October 2021 8:42 AM
To: qua...@li...
Subject: [Quantlib-dev] Porting Guide

Is a there a standard guide on  porting Quantlib to other languages. I have trouble finding any existing HOWTOs or general guides. My goal is to port the library to Common-Lisp.



_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Porting Guide

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

I cant really help, but I do know they use SWIG to port C++ to Python and other languages.

-----Original Message-----
From: Bryte Morio <bry...@qn...> 
Sent: Monday, 11 October 2021 8:42 AM
To: qua...@li...
Subject: [Quantlib-dev] Porting Guide

Is a there a standard guide on  porting Quantlib to other languages. I have trouble finding any existing HOWTOs or general guides. My goal is to port the library to Common-Lisp.



_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Porting Guide

[Bryte M. <bry...@qn...>]

Is a there a standard guide on  porting Quantlib to other languages. I 
have trouble finding any existing HOWTOs or general guides. My goal is 
to port the library to Common-Lisp.

Re: [Quantlib-dev] Black Vasicek/Equity option pricing seems ignoring dividend

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

Hello,
    the paper quoted in the class docs ignores dividends, so I guess the
implementation does that as well.  I'm not sure if a dividend yield can be
added easily to the model.  We should probably document this.

Luigi


On Wed, Sep 8, 2021 at 7:20 PM Lawrence Sum <law...@gm...> wrote:

> Hi Luigi et all,
>
> Recently I used QuantLib 1.22, Visual C++ 2019/Windows for a project and
> discovered that Black Vasicek option pricing seems to be ignoring dividend.
>
> I used the EquityOption.cpp example code to demonstrate the issue below.
> Please let me know if there are some factors that I may have overlooked.
> Thanks in advance.
>
> (1) when dividend = 0
>
>
> Option type = Put
> Maturity = May 17th, 1999
> Underlying price = 36
> Strike = 40
> Risk-free interest rate = 6.000000 %
> Dividend yield = 0.000000 %
> Volatility = 20.000000 %
>
>
> Method                             European      Bermudan      American
> Black-Scholes                      3.844308      N/A           N/A
> ====>Black Vasicek Model                3.818577      N/A           N/A
> Heston semi-analytic               3.844306      N/A           N/A
> Bates semi-analytic                3.844306      N/A           N/A
> Barone-Adesi/Whaley                N/A           N/A           4.459628
> Bjerksund/Stensland                N/A           N/A           4.453064
> Integral                           3.844309      N/A           N/A
> Finite differences                 3.844330      4.360765      4.486113
> Binomial Jarrow-Rudd               3.844132      4.361174      4.486552
> Binomial Cox-Ross-Rubinstein       3.843504      4.360861      4.486415
> Additive equiprobabilities         3.836911      4.354455      4.480097
> Binomial Trigeorgis                3.843557      4.360909      4.486461
> Binomial Tian                      3.844171      4.361176      4.486413
> Binomial Leisen-Reimer             3.844308      4.360713      4.486076
> Binomial Joshi                     3.844308      4.360713      4.486076
> MC (crude)                         3.834522      N/A           N/A
> QMC (Sobol)                        3.844613      N/A           N/A
>
> (2) When dividend is 5%. As you can see  Black Vasicek Model  returns same
> price for dividend=0%.
>
> Option type = Put
> Maturity = May 17th, 1999
> Underlying price = 36
> Strike = 40
> Risk-free interest rate = 6.000000 %
> Dividend yield = 5.000000 %
> Volatility = 20.000000 %
>
>
> Method                             European      Bermudan      American
> Black-Scholes                      4.895555      N/A           N/A
> ====> Black Vasicek Model                3.818577      N/A           N/A
> Heston semi-analytic               4.895554      N/A           N/A
> Bates semi-analytic                4.895554      N/A           N/A
> Barone-Adesi/Whaley                N/A           N/A           5.070904
> Bjerksund/Stensland                N/A           N/A           5.051277
> Integral                           4.895554      N/A           N/A
> Finite differences                 4.895581      5.036359      5.071667
> Binomial Jarrow-Rudd               4.896061      5.037016      5.072378
> Binomial Cox-Ross-Rubinstein       4.894947      5.036011      5.071531
> Additive equiprobabilities         4.897540      5.038650      5.074061
> Binomial Trigeorgis                4.894949      5.036014      5.071534
> Binomial Tian                      4.896303      5.037197      5.072505
> Binomial Leisen-Reimer             4.895554      5.036396      5.071635
> Binomial Joshi                     4.895555      5.036396      5.071635
> MC (crude)                         4.883527      N/A           N/A
> QMC (Sobol)                        4.895873      N/A           N/A
>
> Lawrence Sum
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Black Vasicek/Equity option pricing seems ignoring dividend

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

Hi Luigi et all,

Recently I used QuantLib 1.22, Visual C++ 2019/Windows for a project and
discovered that Black Vasicek option pricing seems to be ignoring dividend.

I used the EquityOption.cpp example code to demonstrate the issue below.
Please let me know if there are some factors that I may have overlooked.
Thanks in advance.

(1) when dividend = 0


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


Method                             European      Bermudan      American
Black-Scholes                      3.844308      N/A           N/A
====>Black Vasicek Model                3.818577      N/A           N/A
Heston semi-analytic               3.844306      N/A           N/A
Bates semi-analytic                3.844306      N/A           N/A
Barone-Adesi/Whaley                N/A           N/A           4.459628
Bjerksund/Stensland                N/A           N/A           4.453064
Integral                           3.844309      N/A           N/A
Finite differences                 3.844330      4.360765      4.486113
Binomial Jarrow-Rudd               3.844132      4.361174      4.486552
Binomial Cox-Ross-Rubinstein       3.843504      4.360861      4.486415
Additive equiprobabilities         3.836911      4.354455      4.480097
Binomial Trigeorgis                3.843557      4.360909      4.486461
Binomial Tian                      3.844171      4.361176      4.486413
Binomial Leisen-Reimer             3.844308      4.360713      4.486076
Binomial Joshi                     3.844308      4.360713      4.486076
MC (crude)                         3.834522      N/A           N/A
QMC (Sobol)                        3.844613      N/A           N/A

(2) When dividend is 5%. As you can see  Black Vasicek Model  returns same
price for dividend=0%.

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


Method                             European      Bermudan      American
Black-Scholes                      4.895555      N/A           N/A
====> Black Vasicek Model                3.818577      N/A           N/A
Heston semi-analytic               4.895554      N/A           N/A
Bates semi-analytic                4.895554      N/A           N/A
Barone-Adesi/Whaley                N/A           N/A           5.070904
Bjerksund/Stensland                N/A           N/A           5.051277
Integral                           4.895554      N/A           N/A
Finite differences                 4.895581      5.036359      5.071667
Binomial Jarrow-Rudd               4.896061      5.037016      5.072378
Binomial Cox-Ross-Rubinstein       4.894947      5.036011      5.071531
Additive equiprobabilities         4.897540      5.038650      5.074061
Binomial Trigeorgis                4.894949      5.036014      5.071534
Binomial Tian                      4.896303      5.037197      5.072505
Binomial Leisen-Reimer             4.895554      5.036396      5.071635
Binomial Joshi                     4.895555      5.036396      5.071635
MC (crude)                         4.883527      N/A           N/A
QMC (Sobol)                        4.895873      N/A           N/A

Lawrence Sum

[Quantlib-dev] QuantLib 1.23 released

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

QuantLib 1.23 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] Wrong UK holiday

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

Fixed in https://github.com/lballabio/QuantLib/pull/1103.  Thanks for the
heads-up!


On Fri, May 28, 2021 at 1:03 PM Ioannis Rigopoulos <qua...@de...>
wrote:

> Problem with the 30 May 2022 of the UK calendar resolved.
>
> It has to do with a one-time exception caused by the Queen's platinum
> jubilee celebration that allocates an extra UK bank holiday on Friday, June
> 3rd 2022.
>
> The usual last Monday of May Spring holiday has been shifted to Thursday,
> June 2nd 2022, making the Monday, May 30th 2022 a business day.
>
> More details at
> https://en.wikipedia.org/wiki/Platinum_Jubilee_of_Elizabeth_II
>
> Please adjust your code settings accordingly.
>
> Ioannis
> On 5/28/2021 12:29 PM, Ioannis Rigopoulos wrote:
>
> Resent it with a proper subject :)
> On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>
> Hi QuantLib users and developers,
>
> I have just discovered the following wrong holiday that affects the
> UnitedKingdom class.
>
> I mention it here because the UK market is extremely important due to the
> many financial instruments traded there and used to calibrate many curves.
>
> All Libor rates, for example, are affected.
>
> *QuantLib regards wrongly the 30 May 2022 as holiday. This date should be
> actually replaced with the two dates 2 June (Spring or Late May) and 3 June
> (Platinum Jubilee of Elizabeth II).*
>
> The interesting is that all remaining holidays until 2049 are correct!
>
> I am not sure why this happens wrt that particular date. I will try to
> investigate and let you know.
>
> Cheers,
>
> Ioannis
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_-2997134614297766375_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

[Quantlib-dev] Wrong UK holiday

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

Resent it with a proper subject :)

On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>
> Hi QuantLib users and developers,
>
> I have just discovered the following wrong holiday that affects the 
> UnitedKingdom class.
>
> I mention it here because the UK market is extremely important due to 
> the many financial instruments traded there and used to calibrate many 
> curves.
>
> All Libor rates, for example, are affected.
>
> *QuantLib regards wrongly the 30 May 2022 as holiday. This date should 
> be actually replaced with the two dates 2 June (Spring or Late May) 
> and 3 June (Platinum Jubilee of Elizabeth II).*
>
> The interesting is that all remaining holidays until 2049 are correct!
>
> I am not sure why this happens wrt that particular date. I will try to 
> investigate and let you know.
>
> Cheers,
>
> Ioannis
>


-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: [Quantlib-dev] Wrong UK holiday

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

Problem with the 30 May 2022 of the UK calendar resolved.

It has to do with a one-time exception caused by the Queen's platinum 
jubilee celebration that allocates an extra UK bank holiday on Friday, 
June 3rd 2022.

The usual last Monday of May Spring holiday has been shifted to 
Thursday, June 2nd 2022, making the Monday, May 30th 2022 a business day.

More details at 
https://en.wikipedia.org/wiki/Platinum_Jubilee_of_Elizabeth_II

Please adjust your code settings accordingly.

Ioannis

On 5/28/2021 12:29 PM, Ioannis Rigopoulos wrote:
>
> Resent it with a proper subject :)
>
> On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>>
>> Hi QuantLib users and developers,
>>
>> I have just discovered the following wrong holiday that affects the 
>> UnitedKingdom class.
>>
>> I mention it here because the UK market is extremely important due to 
>> the many financial instruments traded there and used to calibrate 
>> many curves.
>>
>> All Libor rates, for example, are affected.
>>
>> *QuantLib regards wrongly the 30 May 2022 as holiday. This date 
>> should be actually replaced with the two dates 2 June (Spring or Late 
>> May) and 3 June (Platinum Jubilee of Elizabeth II).*
>>
>> The interesting is that all remaining holidays until 2049 are correct!
>>
>> I am not sure why this happens wrt that particular date. I will try 
>> to investigate and let you know.
>>
>> Cheers,
>>
>> Ioannis
>>


-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: [Quantlib-dev] [Quantlib-users] Pricing of CAP and Swaption with Quantlib

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

Hi QuantLib users and developers,

I have just discovered the following wrong holiday that affects the 
UnitedKingdom class.

I mention it here because the UK market is extremely important due to 
the many financial instruments traded there and used to calibrate many 
curves.

All Libor rates, for example, are affected.

*QuantLib regards wrongly the 30 May 2022 as holiday. This date should 
be actually replaced with the two dates 2 June (Spring or Late May) and 
3 June (Platinum Jubilee of Elizabeth II).*

The interesting is that all remaining holidays until 2049 are correct!

I am not sure why this happens wrt that particular date. I will try to 
investigate and let you know.

Cheers,

Ioannis



-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus