quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] [Quantlib-users] Preliminary tarballs for QuantLib 1.7

[Klaus S. <kl...@sp...>]

Hi Peter,

thanks for highlighting this issue. You're right, the test compares 
uninitialized values with themselves and therefore the explanatory power is 
not as good as it could be. IMO the fix is a one line change and I've sent a PR 
to Luigi.

regards
Klaus


On Saturday, November 14, 2015 06:04:04 PM Peter Caspers wrote:
> I tested QuantLib-1.7.tar.gz, it builds fine with gcc 4.9.3 / boost
> 1.59.0 on my machine. The test-suite runs fine as well, also under
> memcheck, except for a use of uninitialized values triggered from
> 
> VPPTest::testKlugeExtOUMatrixDecomposition()
> 
> but I do not think that this is specific to the release. Maybe Klaus,
> can you have a closer look ? I attach the full memcheck log.
> 
> Two more observations (also unrelated to 1.7, anyway):
> 
> The following files are wrongly marked as executable, is that coming
> from the repository?
> 
> -rwxrwxr-x 1 peter peter   3085 Nov 12 15:38 ql/userconfig.hpp
> -rwxrwxr-x 1 peter peter   7844 Nov 12 15:38 test-suite/observable.cpp
> -rwxrwxr-x 1 peter peter  14561 Nov 12 15:38
> test-suite/quantlibtestsuite.cpp
> 
> Second thing is that when running the test-suite overnight and the
> system date changes in the middle of a test, the check for restoring
> the settings (if applicable to the case) may fail, like here
> 
> utilities.hpp(80): error: in "QuantLib test suite/Forward option
> tests/QuantLib::detail::quantlib_test_case(&ForwardOptionTest::testGreeksIni
> tialization)": Evaluation date not reset
>   before: November 13th, 2015
>   after:  November 14th, 2015
> 
> I guess that would be fixed though by the more general attempt to make
> the suite deterministic w.r.t. the evaluation date (PR #313).
> 
> Peter
> 
> On 13 November 2015 at 17:11, Luigi Ballabio <lui...@gm...> 
wrote:
> > Hi all,
> > 
> >     new tentative tarballs (which by now should be pretty close to release
> > 
> > 1.7, and include a list of changes) are available at
> > <https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>. if
> > you have some time, please try them out and report any problems.
> > 
> > Thanks,
> > 
> >     Luigi
> > 
> > On Fri, Oct 30, 2015 at 5:04 PM Luigi Ballabio <lui...@gm...>
> > 
> > wrote:
> >> Hi all,
> >> 
> >>     tarballs of what will eventually become QuantLib 1.7 are available at
> >> 
> >> <https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>;
> >> if
> >> you have some time, please try them out and report any problems. The list
> >> of changes is not yet available, but a list of the pull requests that
> >> made it into this release are at
> >> <https://github.com/lballabio/quantlib/issues?utf8=%E2%9C%93&q=milestone%
> >> 3A%221.7+release%22+>
> >> 
> >> Thanks,
> >> 
> >>     Luigi
> >> 
> >> --
> >> 
> >> <http://leanpub.com/implementingquantlib>
> >> <http://implementingquantlib.com>
> >> <http://twitter.com/lballabio>
> > 
> > --
> > 
> > <http://leanpub.com/implementingquantlib>
> > <http://implementingquantlib.com>
> > <http://twitter.com/lballabio>
> > 
> > 
> > --------------------------------------------------------------------------
> > ----
> > 
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [Quantlib-users] Reorganization of Git repository

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

On 15 November 2015 at 18:57, Luigi Ballabio wrote:
| We tried that. No joy.

A common trick is to just postfix 'Org'.  Given that quantlib is squatted
upon, we could create QuantLibOrg (in which ever lowercase or uppercase
variant people are happy with).  Can even use hypens: quantlib-org.

Dirk

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

Re: [Quantlib-dev] [Quantlib-users] Reorganization of Git repository

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

It's a shame. However, although I think it is important to have an
official repository and official releases, it is just as fine to have
it under lballabio (for the C++ library) or eehlers (for the excel
stuff), since you are the maintainers anyway.

Breaking up the library would be great, too. Where again the
header-only version (with T instead of Real) comes to my mind, which
is not quite the same, but shares the same advantage (amongst others)
in a sense. No dependency or singleton issues there. Nothing for now,
of course.

On 15 November 2015 at 19:57, Luigi Ballabio <lui...@gm...> wrote:
> We tried that. No joy.
>
> Luigi
>
>
> On 18:41, Sun, Nov 15, 2015 Peter Caspers <pca...@gm...> wrote:
>>
>> you can contact the owner through the github support, I will try to
>> send them a polite message in parallel to Luigi's mail above (in case
>> they are not subscribed to this list - which would be weird somehow,
>> but maybe their project is totally unrelated, who knows)
>> Peter
>>
>> On 15 November 2015 at 10:03, Francois Botha <ig...@gm...> wrote:
>> > Ah, I did a quick check and thought the name was available. I see now it
>> > was
>> > registered in May 2014 - not too long ago! (
>> > https://api.github.com/orgs/quantlib )
>> >
>> > Pity there's no contact info anywhere.
>> >
>> > Francois Botha
>> >
>> > On 13 November 2015 at 13:09, Luigi Ballabio <lui...@gm...>
>> > wrote:
>> >>
>> >> Hi Francois,
>> >>     we talked about that, and I'm not against it. We even tried making
>> >> the
>> >> project account on GitHub, just to find that http://github.com/quantlib
>> >> was
>> >> already taken, so in case we'll have to go for quantlib-official or
>> >> something like it.
>> >>
>> >> (Oh, and if you're the owner of the above project and you're reading
>> >> this,
>> >> we would appreciate a lot if you could rename it and free it. Not
>> >> demanding,
>> >> just asking. It would be a nice gesture.)
>> >>
>> >> For the time being, though, the idea was more that of a federation of
>> >> repos, so mine would be the main one for the core C++ library, Eric's
>> >> would
>> >> be the main one for the Excel addin and so on. We kind of wanted to
>> >> de-bureaucratize the thing, as it were, so that if someone wrote
>> >> another
>> >> QuantLib module there would be no need to ask to be included in the
>> >> "official" club.  I appreciate that it could be confusing, though, so
>> >> we're
>> >> open to feedback on this.
>> >>
>> >> Later,
>> >>     Luigi
>> >>
>> >>
>> >> On Sat, Nov 7, 2015 at 10:16 AM Francois Botha <ig...@gm...>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Isn't this also a good time to create a quantlib organisation account
>> >>> on
>> >>> github and move the official repository to e.g.
>> >>> http://github.com/quantlib/quantlib ? Just a suggestion. I definitely
>> >>> don't
>> >>> want to detract from all the effort that Luigi has put in. It just
>> >>> seems the
>> >>> norm for projects to have their own organisation account on github
>> >>> these
>> >>> days.
>> >>>
>> >>> regards
>> >>>
>> >>> Francois Botha
>> >>>
>> >>> On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
>> >>> wrote:
>> >>>>
>> >>>> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
>> >>>> duplicates. ]
>> >>>>
>> >>>> Hi all,
>> >>>>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
>> >>>>
>> >>>> Shortly after doing that, and in concert with the other maintainers,
>> >>>> I'll reorganize the Git repository so that the current, monolithic
>> >>>> one
>> >>>> containing all the modules will be split into smaller ones, with one
>> >>>> module
>> >>>> per current directory; thus, there will be a repository for the core
>> >>>> C++
>> >>>> library, one for the Excel addin and so on.
>> >>>>
>> >>>> This will make it more convenient for the maintainers to manage the
>> >>>> modules for which they have responsibility, and will also make it a
>> >>>> lot
>> >>>> easier to add new modules.  We had considered doing this when we
>> >>>> migrated
>> >>>> from subversion to git, and in hindsight we should have gone ahead at
>> >>>> that
>> >>>> time.
>> >>>>
>> >>>> I'm aware this will cause inconveniences to the 500+ people that
>> >>>> forked
>> >>>> the repository on GitHub.  I am sorry for this, and I will try to
>> >>>> minimize
>> >>>> the pain: I'll migrate the open pull requests to the new repository,
>> >>>> and
>> >>>> I'll try to make some kind of guide to help those of you with local
>> >>>> changes
>> >>>> to move them to the new fork. In the meantime, your current forks are
>> >>>> not
>> >>>> going away.
>> >>>>
>> >>>> Thanks for the understanding. I'll post a timeline as soon as I have
>> >>>> one.
>> >>>>
>> >>>> Luigi
>> >>>>
>> >>>> --
>> >>>>
>> >>>> <http://leanpub.com/implementingquantlib>
>> >>>> <http://implementingquantlib.com>
>> >>>> <http://twitter.com/lballabio>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>>
>> >>>> _______________________________________________
>> >>>> QuantLib-dev mailing list
>> >>>> Qua...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >>>>
>> >>>
>> >> --
>> >>
>> >> <http://leanpub.com/implementingquantlib>
>> >> <http://implementingquantlib.com>
>> >> <http://twitter.com/lballabio>
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > QuantLib-users mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >
>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>

Re: [Quantlib-dev] [Quantlib-users] Reorganization of Git repository

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

We tried that. No joy.

Luigi

On 18:41, Sun, Nov 15, 2015 Peter Caspers <pca...@gm...> wrote:

> you can contact the owner through the github support, I will try to
> send them a polite message in parallel to Luigi's mail above (in case
> they are not subscribed to this list - which would be weird somehow,
> but maybe their project is totally unrelated, who knows)
> Peter
>
> On 15 November 2015 at 10:03, Francois Botha <ig...@gm...> wrote:
> > Ah, I did a quick check and thought the name was available. I see now it
> was
> > registered in May 2014 - not too long ago! (
> > https://api.github.com/orgs/quantlib )
> >
> > Pity there's no contact info anywhere.
> >
> > Francois Botha
> >
> > On 13 November 2015 at 13:09, Luigi Ballabio <lui...@gm...>
> > wrote:
> >>
> >> Hi Francois,
> >>     we talked about that, and I'm not against it. We even tried making
> the
> >> project account on GitHub, just to find that http://github.com/quantlib
> was
> >> already taken, so in case we'll have to go for quantlib-official or
> >> something like it.
> >>
> >> (Oh, and if you're the owner of the above project and you're reading
> this,
> >> we would appreciate a lot if you could rename it and free it. Not
> demanding,
> >> just asking. It would be a nice gesture.)
> >>
> >> For the time being, though, the idea was more that of a federation of
> >> repos, so mine would be the main one for the core C++ library, Eric's
> would
> >> be the main one for the Excel addin and so on. We kind of wanted to
> >> de-bureaucratize the thing, as it were, so that if someone wrote another
> >> QuantLib module there would be no need to ask to be included in the
> >> "official" club.  I appreciate that it could be confusing, though, so
> we're
> >> open to feedback on this.
> >>
> >> Later,
> >>     Luigi
> >>
> >>
> >> On Sat, Nov 7, 2015 at 10:16 AM Francois Botha <ig...@gm...>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Isn't this also a good time to create a quantlib organisation account
> on
> >>> github and move the official repository to e.g.
> >>> http://github.com/quantlib/quantlib ? Just a suggestion. I definitely
> don't
> >>> want to detract from all the effort that Luigi has put in. It just
> seems the
> >>> norm for projects to have their own organisation account on github
> these
> >>> days.
> >>>
> >>> regards
> >>>
> >>> Francois Botha
> >>>
> >>> On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
> >>> wrote:
> >>>>
> >>>> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
> >>>> duplicates. ]
> >>>>
> >>>> Hi all,
> >>>>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
> >>>>
> >>>> Shortly after doing that, and in concert with the other maintainers,
> >>>> I'll reorganize the Git repository so that the current, monolithic one
> >>>> containing all the modules will be split into smaller ones, with one
> module
> >>>> per current directory; thus, there will be a repository for the core
> C++
> >>>> library, one for the Excel addin and so on.
> >>>>
> >>>> This will make it more convenient for the maintainers to manage the
> >>>> modules for which they have responsibility, and will also make it a
> lot
> >>>> easier to add new modules.  We had considered doing this when we
> migrated
> >>>> from subversion to git, and in hindsight we should have gone ahead at
> that
> >>>> time.
> >>>>
> >>>> I'm aware this will cause inconveniences to the 500+ people that
> forked
> >>>> the repository on GitHub.  I am sorry for this, and I will try to
> minimize
> >>>> the pain: I'll migrate the open pull requests to the new repository,
> and
> >>>> I'll try to make some kind of guide to help those of you with local
> changes
> >>>> to move them to the new fork. In the meantime, your current forks are
> not
> >>>> going away.
> >>>>
> >>>> Thanks for the understanding. I'll post a timeline as soon as I have
> >>>> one.
> >>>>
> >>>> Luigi
> >>>>
> >>>> --
> >>>>
> >>>> <http://leanpub.com/implementingquantlib>
> >>>> <http://implementingquantlib.com>
> >>>> <http://twitter.com/lballabio>
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> QuantLib-dev mailing list
> >>>> Qua...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >>>>
> >>>
> >> --
> >>
> >> <http://leanpub.com/implementingquantlib>
> >> <http://implementingquantlib.com>
> >> <http://twitter.com/lballabio>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] [Quantlib-users] Reorganization of Git repository

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

you can contact the owner through the github support, I will try to
send them a polite message in parallel to Luigi's mail above (in case
they are not subscribed to this list - which would be weird somehow,
but maybe their project is totally unrelated, who knows)
Peter

On 15 November 2015 at 10:03, Francois Botha <ig...@gm...> wrote:
> Ah, I did a quick check and thought the name was available. I see now it was
> registered in May 2014 - not too long ago! (
> https://api.github.com/orgs/quantlib )
>
> Pity there's no contact info anywhere.
>
> Francois Botha
>
> On 13 November 2015 at 13:09, Luigi Ballabio <lui...@gm...>
> wrote:
>>
>> Hi Francois,
>>     we talked about that, and I'm not against it. We even tried making the
>> project account on GitHub, just to find that http://github.com/quantlib was
>> already taken, so in case we'll have to go for quantlib-official or
>> something like it.
>>
>> (Oh, and if you're the owner of the above project and you're reading this,
>> we would appreciate a lot if you could rename it and free it. Not demanding,
>> just asking. It would be a nice gesture.)
>>
>> For the time being, though, the idea was more that of a federation of
>> repos, so mine would be the main one for the core C++ library, Eric's would
>> be the main one for the Excel addin and so on. We kind of wanted to
>> de-bureaucratize the thing, as it were, so that if someone wrote another
>> QuantLib module there would be no need to ask to be included in the
>> "official" club.  I appreciate that it could be confusing, though, so we're
>> open to feedback on this.
>>
>> Later,
>>     Luigi
>>
>>
>> On Sat, Nov 7, 2015 at 10:16 AM Francois Botha <ig...@gm...> wrote:
>>>
>>> Hi,
>>>
>>> Isn't this also a good time to create a quantlib organisation account on
>>> github and move the official repository to e.g.
>>> http://github.com/quantlib/quantlib ? Just a suggestion. I definitely don't
>>> want to detract from all the effort that Luigi has put in. It just seems the
>>> norm for projects to have their own organisation account on github these
>>> days.
>>>
>>> regards
>>>
>>> Francois Botha
>>>
>>> On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
>>> wrote:
>>>>
>>>> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
>>>> duplicates. ]
>>>>
>>>> Hi all,
>>>>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
>>>>
>>>> Shortly after doing that, and in concert with the other maintainers,
>>>> I'll reorganize the Git repository so that the current, monolithic one
>>>> containing all the modules will be split into smaller ones, with one module
>>>> per current directory; thus, there will be a repository for the core C++
>>>> library, one for the Excel addin and so on.
>>>>
>>>> This will make it more convenient for the maintainers to manage the
>>>> modules for which they have responsibility, and will also make it a lot
>>>> easier to add new modules.  We had considered doing this when we migrated
>>>> from subversion to git, and in hindsight we should have gone ahead at that
>>>> time.
>>>>
>>>> I'm aware this will cause inconveniences to the 500+ people that forked
>>>> the repository on GitHub.  I am sorry for this, and I will try to minimize
>>>> the pain: I'll migrate the open pull requests to the new repository, and
>>>> I'll try to make some kind of guide to help those of you with local changes
>>>> to move them to the new fork. In the meantime, your current forks are not
>>>> going away.
>>>>
>>>> Thanks for the understanding. I'll post a timeline as soon as I have
>>>> one.
>>>>
>>>> Luigi
>>>>
>>>> --
>>>>
>>>> <http://leanpub.com/implementingquantlib>
>>>> <http://implementingquantlib.com>
>>>> <http://twitter.com/lballabio>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>
>>>
>> --
>>
>> <http://leanpub.com/implementingquantlib>
>> <http://implementingquantlib.com>
>> <http://twitter.com/lballabio>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-dev] Reorganization of Git repository

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

Ah, I did a quick check and thought the name was available. I see now it
was registered in May 2014 - not too long ago! (
https://api.github.com/orgs/quantlib )

Pity there's no contact info anywhere.

Francois Botha

On 13 November 2015 at 13:09, Luigi Ballabio <lui...@gm...>
wrote:

> Hi Francois,
>     we talked about that, and I'm not against it. We even tried making the
> project account on GitHub, just to find that http://github.com/quantlib was
> already taken, so in case we'll have to go for quantlib-official
> or something like it.
>
> (Oh, and if you're the owner of the above project and you're reading this,
> we would appreciate a lot if you could rename it and free it. Not
> demanding, just asking. It would be a nice gesture.)
>
> For the time being, though, the idea was more that of a federation of
> repos, so mine would be the main one for the core C++ library, Eric's would
> be the main one for the Excel addin and so on. We kind of wanted to
> de-bureaucratize the thing, as it were, so that if someone wrote another
> QuantLib module there would be no need to ask to be included in the
> "official" club.  I appreciate that it could be confusing, though, so we're
> open to feedback on this.
>
> Later,
>     Luigi
>
>
> On Sat, Nov 7, 2015 at 10:16 AM Francois Botha <ig...@gm...> wrote:
>
>> Hi,
>>
>> Isn't this also a good time to create a quantlib organisation account on
>> github and move the official repository to e.g.
>> http://github.com/quantlib/quantlib ? Just a suggestion. I definitely
>> don't want to detract from all the effort that Luigi has put in. It just
>> seems the norm for projects to have their own organisation account on
>> github these days.
>>
>> regards
>>
>> Francois Botha
>>
>> On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
>>> duplicates. ]
>>>
>>> Hi all,
>>>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
>>>
>>> Shortly after doing that, and in concert with the other maintainers,
>>> I'll reorganize the Git repository so that the current, monolithic one
>>> containing all the modules will be split into smaller ones, with one module
>>> per current directory; thus, there will be a repository for the core C++
>>> library, one for the Excel addin and so on.
>>>
>>> This will make it more convenient for the maintainers to manage the
>>> modules for which they have responsibility, and will also make it a lot
>>> easier to add new modules.  We had considered doing this when we migrated
>>> from subversion to git, and in hindsight we should have gone ahead at that
>>> time.
>>>
>>> I'm aware this will cause inconveniences to the 500+ people that forked
>>> the repository on GitHub.  I am sorry for this, and I will try to minimize
>>> the pain: I'll migrate the open pull requests to the new repository, and
>>> I'll try to make some kind of guide to help those of you with local changes
>>> to move them to the new fork. In the meantime, your current forks are not
>>> going away.
>>>
>>> Thanks for the understanding. I'll post a timeline as soon as I have one.
>>>
>>> Luigi
>>>
>>> --
>>>
>>> <http://leanpub.com/implementingquantlib>
>>> <http://implementingquantlib.com>
>>> <http://twitter.com/lballabio>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>>
>> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>

Re: [Quantlib-dev] Preliminary tarballs for QuantLib 1.7

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

I tested QuantLib-1.7.tar.gz, it builds fine with gcc 4.9.3 / boost
1.59.0 on my machine. The test-suite runs fine as well, also under
memcheck, except for a use of uninitialized values triggered from

VPPTest::testKlugeExtOUMatrixDecomposition()

but I do not think that this is specific to the release. Maybe Klaus,
can you have a closer look ? I attach the full memcheck log.

Two more observations (also unrelated to 1.7, anyway):

The following files are wrongly marked as executable, is that coming
from the repository?

-rwxrwxr-x 1 peter peter   3085 Nov 12 15:38 ql/userconfig.hpp
-rwxrwxr-x 1 peter peter   7844 Nov 12 15:38 test-suite/observable.cpp
-rwxrwxr-x 1 peter peter  14561 Nov 12 15:38 test-suite/quantlibtestsuite.cpp

Second thing is that when running the test-suite overnight and the
system date changes in the middle of a test, the check for restoring
the settings (if applicable to the case) may fail, like here

utilities.hpp(80): error: in "QuantLib test suite/Forward option
tests/QuantLib::detail::quantlib_test_case(&ForwardOptionTest::testGreeksInitialization)":
Evaluation date not reset
  before: November 13th, 2015
  after:  November 14th, 2015

I guess that would be fixed though by the more general attempt to make
the suite deterministic w.r.t. the evaluation date (PR #313).

Peter

On 13 November 2015 at 17:11, Luigi Ballabio <lui...@gm...> wrote:
> Hi all,
>     new tentative tarballs (which by now should be pretty close to release
> 1.7, and include a list of changes) are available at
> <https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>. if
> you have some time, please try them out and report any problems.
>
> Thanks,
>     Luigi
>
>
> On Fri, Oct 30, 2015 at 5:04 PM Luigi Ballabio <lui...@gm...>
> wrote:
>>
>> Hi all,
>>     tarballs of what will eventually become QuantLib 1.7 are available at
>> <https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>; if
>> you have some time, please try them out and report any problems. The list of
>> changes is not yet available, but a list of the pull requests that made it
>> into this release are at
>> <https://github.com/lballabio/quantlib/issues?utf8=%E2%9C%93&q=milestone%3A%221.7+release%22+>
>>
>> Thanks,
>>     Luigi
>>
>> --
>>
>> <http://leanpub.com/implementingquantlib>
>> <http://implementingquantlib.com>
>> <http://twitter.com/lballabio>
>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] math constants

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

this is what is shipped with gcc

/* Some useful constants.  */
#if defined __USE_MISC || defined __USE_XOPEN
# define M_E 2.7182818284590452354 /* e */
# define M_LOG2E 1.4426950408889634074 /* log_2 e */
# define M_LOG10E 0.43429448190325182765 /* log_10 e */
# define M_LN2 0.69314718055994530942 /* log_e 2 */
# define M_LN10 2.30258509299404568402 /* log_e 10 */
# define M_PI 3.14159265358979323846 /* pi */
# define M_PI_2 1.57079632679489661923 /* pi/2 */
# define M_PI_4 0.78539816339744830962 /* pi/4 */
# define M_1_PI 0.31830988618379067154 /* 1/pi */
# define M_2_PI 0.63661977236758134308 /* 2/pi */
# define M_2_SQRTPI 1.12837916709551257390 /* 2/sqrt(pi) */
# define M_SQRT2 1.41421356237309504880 /* sqrt(2) */
# define M_SQRT1_2 0.70710678118654752440 /* 1/sqrt(2) */
#endif

/* The above constants are not adequate for computation using `long double's.
   Therefore we provide as an extension constants with similar names as a
   GNU extension.  Provide enough digits for the 128-bit IEEE quad.  */
#ifdef __USE_GNU
# define M_El 2.718281828459045235360287471352662498L /* e */
# define M_LOG2El 1.442695040888963407359924681001892137L /* log_2 e */
# define M_LOG10El 0.434294481903251827651128918916605082L /* log_10 e */
# define M_LN2l 0.693147180559945309417232121458176568L /* log_e 2 */
# define M_LN10l 2.302585092994045684017991454684364208L /* log_e 10 */
# define M_PIl 3.141592653589793238462643383279502884L /* pi */
# define M_PI_2l 1.570796326794896619231321691639751442L /* pi/2 */
# define M_PI_4l 0.785398163397448309615660845819875721L /* pi/4 */
# define M_1_PIl 0.318309886183790671537767526745028724L /* 1/pi */
# define M_2_PIl 0.636619772367581343075535053490057448L /* 2/pi */
# define M_2_SQRTPIl 1.128379167095512573896158903121545172L /* 2/sqrt(pi) */
# define M_SQRT2l 1.414213562373095048801688724209698079L /* sqrt(2) */
# define M_SQRT1_2l 0.707106781186547524400844362104849039L /* 1/sqrt(2) */
#endif

On 13 November 2015 at 17:31, Luigi Ballabio <lui...@gm...> wrote:
> Yes, it might make sense.  But truth be told, I'd be for having less of them
> rather than more.  Which of the macros are already defined by the compilers
> we support?
>
> Luigi
>
>
> On Wed, Nov 4, 2015 at 10:38 AM Peter Caspers <pca...@gm...>
> wrote:
>>
>> Hello Luigi, all,
>>
>> I had a typo in my code and used M_SQRT_2 instead of M_SQRT2, the
>> former being defined as 1 / sqrt(2), but what I wanted was sqrt(2). We
>> also have a macro M_SQRT1_2 with the same value and which seems to
>> have a better name. I find M_SQRT_2 quite confusing and non-intuitive,
>> so I am wondering if we could just deprecate it and remove it in one
>> of the next versions ?
>>
>> There are also some constants whose meaning does not appear
>> crystal-clear at first sight (M_IVLN10, M_LN2LO, M_LN2HI, M_INVLN2).
>> Can someone provide a definition, so that we can maybe add them to the
>> source ?
>>
>> Finally there are some constants with many digits (M_SQRT1_2, M_PI).
>> Since there is no specifier (L) I guess they are always mapped to
>> double by the compiler, which should be 64bit on every platform, so
>> effectively they won't help even if one uses them to initialize a
>> __float128 etc. ? Maybe we should rather do it like GNU and add
>> versions of the macros like M_PIl, M_SQRT1_2l defining more digits and
>> with the L suffix ? Then we would also be in line with gcc.
>>
>> What do you think ?
>>
>> Best regards
>> Peter
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>

Re: [Quantlib-dev] math constants

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

Yes, it might make sense.  But truth be told, I'd be for having less of
them rather than more.  Which of the macros are already defined by the
compilers we support?

Luigi


On Wed, Nov 4, 2015 at 10:38 AM Peter Caspers <pca...@gm...>
wrote:

> Hello Luigi, all,
>
> I had a typo in my code and used M_SQRT_2 instead of M_SQRT2, the
> former being defined as 1 / sqrt(2), but what I wanted was sqrt(2). We
> also have a macro M_SQRT1_2 with the same value and which seems to
> have a better name. I find M_SQRT_2 quite confusing and non-intuitive,
> so I am wondering if we could just deprecate it and remove it in one
> of the next versions ?
>
> There are also some constants whose meaning does not appear
> crystal-clear at first sight (M_IVLN10, M_LN2LO, M_LN2HI, M_INVLN2).
> Can someone provide a definition, so that we can maybe add them to the
> source ?
>
> Finally there are some constants with many digits (M_SQRT1_2, M_PI).
> Since there is no specifier (L) I guess they are always mapped to
> double by the compiler, which should be 64bit on every platform, so
> effectively they won't help even if one uses them to initialize a
> __float128 etc. ? Maybe we should rather do it like GNU and add
> versions of the macros like M_PIl, M_SQRT1_2l defining more digits and
> with the L suffix ? Then we would also be in line with gcc.
>
> What do you think ?
>
> Best regards
> Peter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] Preliminary tarballs for QuantLib 1.7

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

Hi all,
    new tentative tarballs (which by now should be pretty close to release
1.7, and include a list of changes) are available at <
https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>. if
you have some time, please try them out and report any problems.

Thanks,
    Luigi


On Fri, Oct 30, 2015 at 5:04 PM Luigi Ballabio <lui...@gm...>
wrote:

> Hi all,
>     tarballs of what will eventually become QuantLib 1.7 are available at <
> https://sourceforge.net/projects/quantlib/files/QuantLib/prerelease/>; if
> you have some time, please try them out and report any problems. The list
> of changes is not yet available, but a list of the pull requests that made
> it into this release are at <
> https://github.com/lballabio/quantlib/issues?utf8=%E2%9C%93&q=milestone%3A%221.7+release%22+
> >
>
> Thanks,
>     Luigi
>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] Reorganization of Git repository

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

Hi Francois,
    we talked about that, and I'm not against it. We even tried making the
project account on GitHub, just to find that http://github.com/quantlib was
already taken, so in case we'll have to go for quantlib-official
or something like it.

(Oh, and if you're the owner of the above project and you're reading this,
we would appreciate a lot if you could rename it and free it. Not
demanding, just asking. It would be a nice gesture.)

For the time being, though, the idea was more that of a federation of
repos, so mine would be the main one for the core C++ library, Eric's would
be the main one for the Excel addin and so on. We kind of wanted to
de-bureaucratize the thing, as it were, so that if someone wrote another
QuantLib module there would be no need to ask to be included in the
"official" club.  I appreciate that it could be confusing, though, so we're
open to feedback on this.

Later,
    Luigi

On Sat, Nov 7, 2015 at 10:16 AM Francois Botha <ig...@gm...> wrote:

> Hi,
>
> Isn't this also a good time to create a quantlib organisation account on
> github and move the official repository to e.g.
> http://github.com/quantlib/quantlib ? Just a suggestion. I definitely
> don't want to detract from all the effort that Luigi has put in. It just
> seems the norm for projects to have their own organisation account on
> github these days.
>
> regards
>
> Francois Botha
>
> On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
>> duplicates. ]
>>
>> Hi all,
>>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
>>
>> Shortly after doing that, and in concert with the other maintainers, I'll
>> reorganize the Git repository so that the current, monolithic one
>> containing all the modules will be split into smaller ones, with one module
>> per current directory; thus, there will be a repository for the core C++
>> library, one for the Excel addin and so on.
>>
>> This will make it more convenient for the maintainers to manage the
>> modules for which they have responsibility, and will also make it a lot
>> easier to add new modules.  We had considered doing this when we migrated
>> from subversion to git, and in hindsight we should have gone ahead at that
>> time.
>>
>> I'm aware this will cause inconveniences to the 500+ people that forked
>> the repository on GitHub.  I am sorry for this, and I will try to minimize
>> the pain: I'll migrate the open pull requests to the new repository, and
>> I'll try to make some kind of guide to help those of you with local changes
>> to move them to the new fork. In the meantime, your current forks are not
>> going away.
>>
>> Thanks for the understanding. I'll post a timeline as soon as I have one.
>>
>> Luigi
>>
>> --
>>
>> <http://leanpub.com/implementingquantlib>
>> <http://implementingquantlib.com>
>> <http://twitter.com/lballabio>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
> --

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] Quantlib / Python: 'swig' not recognized

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

Glad it helped.  Just to explain: you can build the bindings without SWIG
if you start from a QuantLib-SWIG release, because we generate the wrappers
ourselves and include them in the archive.  If you check out the sources
from the git repo, then the wrappers are not included and you need SWIG.

Luigi


On Thu, Nov 5, 2015 at 10:29 AM Michel <mhb...@gm...> wrote:

> Hi Luigi,
>
> Thanks. I figured out that i could build the python bindings without SWIG.
>
> I don't have the issue anymore after having installed the prebuilt SWIG
> binaries found here: http://www.swig.org/download.html
>
> BR
>
> Michel
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/Quantlib-Python-swig-not-recognized-tp17024p17032.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] Reorganization of Git repository

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

Hi,

Isn't this also a good time to create a quantlib organisation account on
github and move the official repository to e.g.
http://github.com/quantlib/quantlib ? Just a suggestion. I definitely don't
want to detract from all the effort that Luigi has put in. It just seems
the norm for projects to have their own organisation account on github
these days.

regards

Francois Botha

On 26 October 2015 at 16:09, Luigi Ballabio <lui...@gm...>
wrote:

> [ cross-posted to quantlib-users and quantlib-dev; apologies for any
> duplicates. ]
>
> Hi all,
>     I'm currently 3 or 4 issues away from setting up the 1.7 release.
>
> Shortly after doing that, and in concert with the other maintainers, I'll
> reorganize the Git repository so that the current, monolithic one
> containing all the modules will be split into smaller ones, with one module
> per current directory; thus, there will be a repository for the core C++
> library, one for the Excel addin and so on.
>
> This will make it more convenient for the maintainers to manage the
> modules for which they have responsibility, and will also make it a lot
> easier to add new modules.  We had considered doing this when we migrated
> from subversion to git, and in hindsight we should have gone ahead at that
> time.
>
> I'm aware this will cause inconveniences to the 500+ people that forked
> the repository on GitHub.  I am sorry for this, and I will try to minimize
> the pain: I'll migrate the open pull requests to the new repository, and
> I'll try to make some kind of guide to help those of you with local changes
> to move them to the new fork. In the meantime, your current forks are not
> going away.
>
> Thanks for the understanding. I'll post a timeline as soon as I have one.
>
> Luigi
>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Re: [Quantlib-dev] Quantlib / Python: 'swig' not recognized

[Michel <mhb...@gm...>]

Hi Luigi,

Thanks. I figured out that i could build the python bindings without SWIG.

I don't have the issue anymore after having installed the prebuilt SWIG
binaries found here: http://www.swig.org/download.html

BR

Michel



--
View this message in context: http://quantlib.10058.n7.nabble.com/Quantlib-Python-swig-not-recognized-tp17024p17032.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] math constants

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

Hello Luigi, all,

I had a typo in my code and used M_SQRT_2 instead of M_SQRT2, the
former being defined as 1 / sqrt(2), but what I wanted was sqrt(2). We
also have a macro M_SQRT1_2 with the same value and which seems to
have a better name. I find M_SQRT_2 quite confusing and non-intuitive,
so I am wondering if we could just deprecate it and remove it in one
of the next versions ?

There are also some constants whose meaning does not appear
crystal-clear at first sight (M_IVLN10, M_LN2LO, M_LN2HI, M_INVLN2).
Can someone provide a definition, so that we can maybe add them to the
source ?

Finally there are some constants with many digits (M_SQRT1_2, M_PI).
Since there is no specifier (L) I guess they are always mapped to
double by the compiler, which should be 64bit on every platform, so
effectively they won't help even if one uses them to initialize a
__float128 etc. ? Maybe we should rather do it like GNU and add
versions of the macros like M_PIl, M_SQRT1_2l defining more digits and
with the L suffix ? Then we would also be in line with gcc.

What do you think ?

Best regards
Peter

Re: [Quantlib-dev] Quantlib / Python: 'swig' not recognized

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

You're missing swig. See  <http://www.swig.org/>.

Luigi


On Wed, Nov 4, 2015 at 9:53 AM Michel <mhb...@gm...> wrote:

> Hi,
>
> I'm trying to build Quantlib SWIG for python, but i face the following
> issue
> (i tried to find an answer to my problem in the forum but i did not find
> any
> close solution).
>
> I have checkouted Quantlib 1.7 with Git, built it with Visual Express 2008.
>
> Then i specified the LIB, QL_DIR and INCLUDE envir variables.
>
> now i use the python setup.py wrap command, but i get an error 'swig' is
> not
> recognized as an internal or external command.
>
> FYI, i use Anaconda 2.7 32bit.
>
> What am i missing?
>
> Thanks
>
> Michel
>
>
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/Quantlib-Python-swig-not-recognized-tp17024.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

Re: [Quantlib-dev] 答复: Binomial American Options with Discrete Dividends & Greeks

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

In the test suite,
https://github.com/lballabio/quantlib/blob/master/QuantLib/test-suite/dividendoption.cpp#L677

The lines from 694 to 725 initialize the option and its market data. Those
from 741 to 757 calculates the value and the greeks, and compares the
available greeks with those calculated by bumping the data (e.g., to
calculate the delta modify thevalue of the underlying, recalculate, and see
how much the value has changed; the same approach can be  used for all the
other greeks). For an American option, you'll need to specify an American
exercise: see line 827.

Luigi


On Tue, Nov 3, 2015 at 11:32 AM jamesquant <jam...@ho...> wrote:

> Hi. Do you have an example of how to do this?
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/Binomial-American-Options-with-Discrete-Dividends-Greeks-tp17012p17017.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

[Quantlib-dev] Quantlib / Python: 'swig' not recognized

[Michel <mhb...@gm...>]

Hi,

I'm trying to build Quantlib SWIG for python, but i face the following issue
(i tried to find an answer to my problem in the forum but i did not find any
close solution).

I have checkouted Quantlib 1.7 with Git, built it with Visual Express 2008.

Then i specified the LIB, QL_DIR and INCLUDE envir variables.

now i use the python setup.py wrap command, but i get an error 'swig' is not
recognized as an internal or external command.

FYI, i use Anaconda 2.7 32bit.

What am i missing?

Thanks

Michel





--
View this message in context: http://quantlib.10058.n7.nabble.com/Quantlib-Python-swig-not-recognized-tp17024.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Quantlib Freelancer C# required

[jamesquant <jam...@ho...>]

Looking for a freelancer to code in c# American option pricing with discrete
dividends and delta, gamma, theta, Vega and rho greeks. Binomial solution
would be fine.



--
View this message in context: http://quantlib.10058.n7.nabble.com/Quantlib-Freelancer-C-required-tp17023.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] reposit/QuantLibXL 1.7 prerelease

[Eric E. <eri...@re...>]

Hi All,

I packaged a prerelease build of QuantLibXL 1.7:

    http://sourceforge.net/projects/quantlib/files/QuantLibXL/prerelease/

This release is based on the reposit platform which is a work in
progress.

Here is the documentation for installing the binary release:

    http://quantlib.org/reposit/docs/latest/qlxl_install.html

Here is the documentation for compiling from source:

    http://quantlib.org/reposit/docs/latest/build_qlxl.html

Feedback is welcome.

Kind Regards,
Eric

Re: [Quantlib-dev] Touch option pricing

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

Hello,
    they're called barrier options in QuantLib.  You can find examples in
test-suite/barrieroption.cpp and test-suite/doublebarrieroption.cpp.

Luigi


On Mon, Nov 2, 2015 at 8:44 AM sansan <san...@ya...> wrote:

> Hello,
>         I am new to quantlib. I am searching for example code to price
> Touch
> option (Single/Double). Please let me know how it is priced or point me to
> any example.
>
> Regards,
> San
>
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/Touch-option-pricing-tp17013.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>

[Quantlib-dev] Quantlib methods for option pricing

[chandu123 <cha...@gm...>]

Hi,

I want to use QuantLib for valuation of CME option symbol LNEF6 C3500, which
QL methods should I use to match the values below?

I need to match values obtained by my trader using CQG which uses a binomial
options model.

LNEF6 C3500 is a European call option on JAN16 natural gas futures with a
3.5 strike. On Sep 23rd 2015, the option price was valued at 0.0745 

with a delta of 22.85 and gamma of 0.047. These values were obtained using
the CQG platform by Global Futures 

(http://www.globalfutures.com/index.asp?refid=fscqg)

The parameters are:


double volatility = 0.4251; 
double strike = 3.5;
double underlyingPrice = 2.919;
double daysToExpiration = 96.12;
double ir = 0.015; // 1.5% interest rate
String optionType = call;

Which QL method can I call to match the option price, delta and gamma?

Thanks,
chandu




--
View this message in context: http://quantlib.10058.n7.nabble.com/Quantlib-methods-for-option-pricing-tp17018.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] 答复: Binomial American Options with Discrete Dividends & Greeks

[jamesquant <jam...@ho...>]

Hi. Do you have an example of how to do this?



--
View this message in context: http://quantlib.10058.n7.nabble.com/Binomial-American-Options-with-Discrete-Dividends-Greeks-tp17012p17017.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] 答复: Binomial American Options with Discrete Dividends & Greeks

[cheng l. <scr...@gm...>]

Just bump an recalculate。。。

-----邮件原件-----
发件人: jamesquant [mailto:jam...@ho...] 
发送时间: 2015年11月2日 0:11
收件人: qua...@li...
主题: [Quantlib-dev] Binomial American Options with Discrete Dividends &
Greeks

How do I calculate using quantlib Binomial American Options with Discrete
Dividends & Greeks? 



--
View this message in context:
http://quantlib.10058.n7.nabble.com/Binomial-American-Options-with-Discrete-
Dividends-Greeks-tp17012.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

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

Re: [Quantlib-dev] Binomial American Options with Discrete Dividends & Greeks

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

Hi James,
    there's no binomial engine for that, but you can use
the FDDividendAmericanEngine and DividendVanillaOption classes; see
test-suite/dividendoption.cpp for an example. Due to the way the numerical
calculation is performed, the engine doesn't provide all the Greeks
natively; only delta and gamma. For the others, you'll have to bump the
inputs and reprice the option.

Luigi


On Mon, Nov 2, 2015 at 9:57 AM jamesquant <jam...@ho...> wrote:

> How do I calculate using quantlib Binomial American Options with Discrete
> Dividends & Greeks?
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/Binomial-American-Options-with-Discrete-Dividends-Greeks-tp17012.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
-- 

<http://leanpub.com/implementingquantlib>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>