quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Reorganization of Git repository

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

Hi all,
    Eric and I just finished splitting the QuantLib git repository in
smaller modules. The main forks for the new, smaller repos are:

QuantLib: https://github.com/lballabio/QuantLib
QuantLib-SWIG: https://github.com/lballabio/QuantLib-SWIG
reposit: https://github.com/eehlers/reposit
QuantLibAddin: https://github.com/eehlers/QuantLibAddin
QuantLibXL: https://github.com/eehlers/QuantLibXL

Eric's modules refer to the new reposit build.  The old build is still
hosted at https://github.com/eehlers/quantlib for the time being.

For those of you that had forked the old repository, see the instructions
at http://quantlib.org/forkmigration.shtml for migrating any modifications
you want to keep.

Thanks for your patience,
    Luigi



On Thu, Dec 10, 2015 at 5:36 PM Luigi Ballabio <lui...@gm...>
wrote:

> Hi all,
>     Eric and I will be splitting the QuantLib git repository in smaller
> modules in the next few days (see my previous post, quoted below, for more
> details).  Once it's done, most of you that forked it on GitHub or cloned
> it locally can probably just fork or clone again the modules you're
> interested in. For those of you that have additional branches you want to
> keep, I'll be posting instructions for migrating them to the new modules.
>
> Later,
>     Luigi
>
>
> On Mon, Oct 26, 2015 at 3:09 PM 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>
>>
> --
>
> <http://leanpub.com/implementingquantlib>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>
-- 

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

[Quantlib-dev] How do I contribute?

[Prudhvi G. <pru...@gm...>]

I have experience in C++ programming and a Masters in Computer Science. I
am interested in moving to finance. This would be a great platform to learn
about and contribute to C++ in financial applications. Can someone please
let me know how can I contribute to Quantlib.

Thanks in advance.

[Quantlib-dev] ObjectHandler / QuantLibAddin / QuantLibXL 1.7 Released

[Paolo M. <maz...@li...>]

Hi All, ObjectHandler / QuantLibAddin / QuantLibXL version 1.7 (using gensrc) has been released.  Here is the link to
the downloads page: http://sourceforge.net/projects/quantlib/files/
Here are the links to the updated web sites:  http://www.objecthandler.org

 http://www.quantlibaddin.org

 http://www.quantlibxl.org The binary release of QuantLibXL includes XLLs
for 32- and 64-bit Excel.  The source
code for QuantLibXL 1.7.0 is compatible with QuantLib 1.7.0. This release includes the updated Rate Curve Framework presented at the QuantLib UserMeeting 15. This application only works under 32-bit Excel. Kind Regards,





































Paolo 		 	   		  

Re: [Quantlib-dev] Reorganization of Git repository

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

Hi all,
    Eric and I will be splitting the QuantLib git repository in smaller
modules in the next few days (see my previous post, quoted below, for more
details).  Once it's done, most of you that forked it on GitHub or cloned
it locally can probably just fork or clone again the modules you're
interested in. For those of you that have additional branches you want to
keep, I'll be posting instructions for migrating them to the new modules.

Later,
    Luigi

On Mon, Oct 26, 2015 at 3:09 PM 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>
>
-- 

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

Re: [Quantlib-dev] EditorConfig files

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

A once-off total reformatting is probably not worth your time :)
Ok, send me a PR.

Luigi

On Thu, Dec 10, 2015 at 7:30 AM Francois Botha <ig...@gm...> wrote:

> I think it's up to the specific plugin of whatever IDE one uses on how the
> configuration is applied. But I agree with you. One doesn't want to see
> non-trivial diffs in the commits. I would think that a user who has the
> knowledge to consume these format configuration files would also know to
> remove irrelevant changes when doing a commit?
>
> And I assume a once-off total reformatting of the project is going to
> create too many conflicts on all the branches and forks? I'm not too
> concerned with how the curly braces are positioned, but consistent
> indentation and trailing whitespace removal would be nice for a start.
>
> Francois
>
> Francois Botha
>
> On 9 December 2015 at 17:04, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> No particular objection.  I'd just try to avoid having cosmetic changes
>> making it more difficult to see what actually changed in a commit, so I'd
>> suggest to configure editors so that they only apply the conventions to
>> edited lines, not over the whole file. Is this possible?
>>
>> Luigi
>>
>> On Wed, Nov 25, 2015 at 10:18 AM Francois Botha <ig...@gm...> wrote:
>>
>>> Hi,
>>>
>>> I was wondering whether there are any objections against adding
>>> .editorconfig files to all the projects. This will assist in maintaining
>>> consistent formatting (especially indentation). Most IDEs are supported.
>>> See http://editorconfig.org/ for more info.
>>>
>>> regards,
>>> Francois Botha
>>>
>>> ------------------------------------------------------------------------------
>>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>>> Give your users amazing mobile app experiences with Intel(R) XDK.
>>> Use one codebase in this all-in-one HTML5 development environment.
>>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>>> OSs.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
>>> _______________________________________________
>>> 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>
>>
>
> --

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

Re: [Quantlib-dev] EditorConfig files

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

I think it's up to the specific plugin of whatever IDE one uses on how the
configuration is applied. But I agree with you. One doesn't want to see
non-trivial diffs in the commits. I would think that a user who has the
knowledge to consume these format configuration files would also know to
remove irrelevant changes when doing a commit?

And I assume a once-off total reformatting of the project is going to
create too many conflicts on all the branches and forks? I'm not too
concerned with how the curly braces are positioned, but consistent
indentation and trailing whitespace removal would be nice for a start.

Francois

Francois Botha

On 9 December 2015 at 17:04, Luigi Ballabio <lui...@gm...>
wrote:

> No particular objection.  I'd just try to avoid having cosmetic changes
> making it more difficult to see what actually changed in a commit, so I'd
> suggest to configure editors so that they only apply the conventions to
> edited lines, not over the whole file. Is this possible?
>
> Luigi
>
> On Wed, Nov 25, 2015 at 10:18 AM Francois Botha <ig...@gm...> wrote:
>
>> Hi,
>>
>> I was wondering whether there are any objections against adding
>> .editorconfig files to all the projects. This will assist in maintaining
>> consistent formatting (especially indentation). Most IDEs are supported.
>> See http://editorconfig.org/ for more info.
>>
>> regards,
>> Francois Botha
>>
>> ------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
>> _______________________________________________
>> 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] Build failing for 1.6.2 on Mac OS X.

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

No, I'm referring to the note on the installation page that says:  "Users
have reported linking problems since Mac OS X 10.9; the solution (thanks to
Albert Azout for pointing it out) seems to be to set the environment flags
CXXFLAGS and LDFLAGS to -stdlib=libstdc++ -mmacosx-version-min=10.6 before
compiling."

Did you try it?


On Wed, Dec 9, 2015 at 4:46 PM krsingh.chandan <
krs...@da...> wrote:

> HI Luigi,
>
> I had tried to compile it as static library rather then dynamic as default
> but problem persisted.
>
> Thanks,
> Chandan
>
> On 09-Dec-2015, at 8:23 PM, Luigi Ballabio <lui...@gm...>
> wrote:
>
> Hello,
>     did you try setting environment variables as suggested in the note
> towards the end of <http://quantlib.org/install/macosx.shtml>?
>
> Luigi
>
>
> On Wed, Dec 2, 2015 at 10:39 AM krsingh.chandan <
> krs...@da...> wrote:
>
>> Hi All,
>>
>> I am trying to compile Quantlib on Mac OS X AI Captain, and getting error
>> while building test_suit. Please find the error as under for reference:
>>
>> Undefined symbols for architecture x86_64:
>>
>> "boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result
>> const&, boost::unit_test::lazy_ostream const&,
>> boost::unit_test::basic_cstring<char const>, unsigned long,
>> boost::test_tools::tt_detail::tool_level,
>> boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced
>> from:
>>       QuantLib::detail::quantlib_test_case::operator()() const in
>> quantlibtestsuite.o
>>       void (anonymous
>> namespace)::testFdGreeks<QuantLib::FDShoutEngine<QuantLib::CrankNicolson>
>> >() in americanoption.o
>>       void (anonymous
>> namespace)::testFdGreeks<QuantLib::FDAmericanEngine<QuantLib::CrankNicolson>
>> >() in americanoption.o
>>       AmericanOptionTest::testFdValues()       in americanoption.o
>>       AmericanOptionTest::testJuValues()       in americanoption.o
>>       AmericanOptionTest::testBjerksundStenslandValues()       in
>> americanoption.o
>>       AmericanOptionTest::testBaroneAdesiWhaleyValues()       in
>> americanoption.o
>>       ...
>>
>> "boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char
>> const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
>> const&)", referenced from:
>>       init_unit_test_suite(int, char**) in quantlibtestsuite.o
>>
>> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
>> const&, boost::unit_test::basic_cstring<char const>) in americanoption.o
>>       AmortizingBondTest::suite()      in amortizingbond.o
>>       ArrayTest::suite()     in array.o
>>
>> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
>> const&, boost::unit_test::basic_cstring<char const>) in asianoptions.o
>>
>> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
>> const&, boost::unit_test::basic_cstring<char const>) in assetswap.o
>>       AutocovariancesTest::suite()      in autocovariances.o
>>       ...
>> ld: symbol(s) not found for architecture x86_64
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [quantlib-test-suite] Error 1
>> make: *** [all-recursive] Error 1
>>
>> It look like some fine tuning of ./configure file is required. Please
>> help.
>>
>> Thanks,
>> Chandan
>>
>> ------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>> _______________________________________________
>> 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>
>
>
> --

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

Re: [Quantlib-dev] Build failing for 1.6.2 on Mac OS X.

[krsingh.chandan <krs...@da...>]

HI Luigi,

I had tried to compile it as static library rather then dynamic as default but problem persisted.

Thanks,
Chandan

On 09-Dec-2015, at 8:23 PM, Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>> wrote:

Hello,
    did you try setting environment variables as suggested in the note towards the end of <http://quantlib.org/install/macosx.shtml>?

Luigi


On Wed, Dec 2, 2015 at 10:39 AM krsingh.chandan <krs...@da...<mailto:krs...@da...>> wrote:
Hi All,

I am trying to compile Quantlib on Mac OS X AI Captain, and getting error while building test_suit. Please find the error as under for reference:

Undefined symbols for architecture x86_64:
  "boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced from:
      QuantLib::detail::quantlib_test_case::operator()() const in quantlibtestsuite.o
      void (anonymous namespace)::testFdGreeks<QuantLib::FDShoutEngine<QuantLib::CrankNicolson> >() in americanoption.o
      void (anonymous namespace)::testFdGreeks<QuantLib::FDAmericanEngine<QuantLib::CrankNicolson> >() in americanoption.o
      AmericanOptionTest::testFdValues()       in americanoption.o
      AmericanOptionTest::testJuValues()       in americanoption.o
      AmericanOptionTest::testBjerksundStenslandValues()       in americanoption.o
      AmericanOptionTest::testBaroneAdesiWhaleyValues()       in americanoption.o
      ...
  "boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&)", referenced from:
      init_unit_test_suite(int, char**) in quantlibtestsuite.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in americanoption.o
      AmortizingBondTest::suite()      in amortizingbond.o
      ArrayTest::suite()     in array.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in asianoptions.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in assetswap.o
      AutocovariancesTest::suite()      in autocovariances.o
      ...
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [quantlib-test-suite] Error 1
make: *** [all-recursive] Error 1

It look like some fine tuning of ./configure file is required. Please help.

Thanks,
Chandan
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140_______________________________________________
QuantLib-dev mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
--

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

Re: [Quantlib-dev] EditorConfig files

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

No particular objection.  I'd just try to avoid having cosmetic changes
making it more difficult to see what actually changed in a commit, so I'd
suggest to configure editors so that they only apply the conventions to
edited lines, not over the whole file. Is this possible?

Luigi

On Wed, Nov 25, 2015 at 10:18 AM Francois Botha <ig...@gm...> wrote:

> Hi,
>
> I was wondering whether there are any objections against adding
> .editorconfig files to all the projects. This will assist in maintaining
> consistent formatting (especially indentation). Most IDEs are supported.
> See http://editorconfig.org/ for more info.
>
> regards,
> Francois Botha
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> 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] Build failing for 1.6.2 on Mac OS X.

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

Hello,
    did you try setting environment variables as suggested in the note
towards the end of <http://quantlib.org/install/macosx.shtml>?

Luigi


On Wed, Dec 2, 2015 at 10:39 AM krsingh.chandan <
krs...@da...> wrote:

> Hi All,
>
> I am trying to compile Quantlib on Mac OS X AI Captain, and getting error
> while building test_suit. Please find the error as under for reference:
>
> Undefined symbols for architecture x86_64:
>
> "boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result
> const&, boost::unit_test::lazy_ostream const&,
> boost::unit_test::basic_cstring<char const>, unsigned long,
> boost::test_tools::tt_detail::tool_level,
> boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced
> from:
>       QuantLib::detail::quantlib_test_case::operator()() const in
> quantlibtestsuite.o
>       void (anonymous
> namespace)::testFdGreeks<QuantLib::FDShoutEngine<QuantLib::CrankNicolson>
> >() in americanoption.o
>       void (anonymous
> namespace)::testFdGreeks<QuantLib::FDAmericanEngine<QuantLib::CrankNicolson>
> >() in americanoption.o
>       AmericanOptionTest::testFdValues()       in americanoption.o
>       AmericanOptionTest::testJuValues()       in americanoption.o
>       AmericanOptionTest::testBjerksundStenslandValues()       in
> americanoption.o
>       AmericanOptionTest::testBaroneAdesiWhaleyValues()       in
> americanoption.o
>       ...
>
> "boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char
> const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
> const&)", referenced from:
>       init_unit_test_suite(int, char**) in quantlibtestsuite.o
>
> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
> const&, boost::unit_test::basic_cstring<char const>) in americanoption.o
>       AmortizingBondTest::suite()      in amortizingbond.o
>       ArrayTest::suite()     in array.o
>
> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
> const&, boost::unit_test::basic_cstring<char const>) in asianoptions.o
>
> boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused>
> const&, boost::unit_test::basic_cstring<char const>) in assetswap.o
>       AutocovariancesTest::suite()      in autocovariances.o
>       ...
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
> make[1]: *** [quantlib-test-suite] Error 1
> make: *** [all-recursive] Error 1
>
> It look like some fine tuning of ./configure file is required. Please help.
>
> Thanks,
> Chandan
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> 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] reposit / QuantLibXL 1.7 Released

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

Hi All,

There will be two releases of QuantLibXL 1.7.  One will be based on the
existing ObjectHandler/gensrc platform.  This build is stable.

This message relates to the release of other build, which is based on
the new reposit platform.  This build is a work in progress and is
unstable.

The main objectives of the new build are:

1) Autogeneration of object wrapper code, which in the old build must
be implemented by hand.

2) Simplify the process of exporting functions from C++ libraries (such
as QuantLib) to their corresponding addins (such as QuantLibXL).

A high level comparison of the two QuantLibXL builds is available at
this link:

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

This is the home page for the reposit project:

    http://quantlib.org/reposit/index.html

Here is the link to download the files for the 1.7 release of reposit
and QuantLibXL:

    https://sourceforge.net/projects/quantlib/files/reposit/1.7/

Here is the link to the documentation for all builds of the 1.7 release
of reposit and QuantLibXL, including a binary release of QuantLibXL,
and source code builds for Windows and Linux:

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

For any questions please use the mailing list:

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

reposit has been deployed to the =countify platform, allowing
spreadsheets to be shared in the cloud in real time.  For a free demo
please visit the home page of the =countify project:

    http://www.countify.com/

Kind Regards,
Eric

[Quantlib-dev] Build failing for 1.6.2 on Mac OS X.

[krsingh.chandan <krs...@da...>]

Hi All,

I am trying to compile Quantlib on Mac OS X AI Captain, and getting error while building test_suit. Please find the error as under for reference:

Undefined symbols for architecture x86_64:
  "boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced from:
      QuantLib::detail::quantlib_test_case::operator()() const in quantlibtestsuite.o
      void (anonymous namespace)::testFdGreeks<QuantLib::FDShoutEngine<QuantLib::CrankNicolson> >() in americanoption.o
      void (anonymous namespace)::testFdGreeks<QuantLib::FDAmericanEngine<QuantLib::CrankNicolson> >() in americanoption.o
      AmericanOptionTest::testFdValues()       in americanoption.o
      AmericanOptionTest::testJuValues()       in americanoption.o
      AmericanOptionTest::testBjerksundStenslandValues()       in americanoption.o
      AmericanOptionTest::testBaroneAdesiWhaleyValues()       in americanoption.o
      ...
  "boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&)", referenced from:
      init_unit_test_suite(int, char**) in quantlibtestsuite.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in americanoption.o
      AmortizingBondTest::suite()      in amortizingbond.o
      ArrayTest::suite()     in array.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in asianoptions.o
      boost::unit_test::make_test_case(boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>) in assetswap.o
      AutocovariancesTest::suite()      in autocovariances.o
      ...
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [quantlib-test-suite] Error 1
make: *** [all-recursive] Error 1

It look like some fine tuning of ./configure file is required. Please help.

Thanks,
Chandan

Re: [Quantlib-dev] Test suite run time

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

Hello,

to give a benchmark, it takes around 8h to run memcheck on the whole
test-suite, which means a slow-down factor of approximately 50x. This is
with -O3 though, which may hide or produce bogus uninitialized value errors
under certain (but rare) circumstances (according to the valgrind
documentation). Since its diagnostics concerning memory errors seems pretty
much exhaustive (it is e.g. comparable to clang's address + memory + leak
sanitizer), I am wondering what Visual Studio is (thinking it is) doing? Is
it turning off optimization maybe? Or is it doing something in the
direction of thread-safety?

Is it possible to switch optimization levels, debug symbol generation and
sanitizing code instrumentation separately from each other in the studio?
If yes, one can maybe find a viable compromise for these settings between
running time and error sensitivity depending on what exactly one is
expecting.

Peter



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

> Hi Francois,
>     in Release mode, it should be in the neighborhood of 10 minutes.  I
> see you're running it in Debug mode, though; it adds all kinds of
> additional run-time checks, so it will take way more. I'm not sure how much
> exactly, since I haven't run it in a long time...
>
> Luigi
>
>
> On Fri, Nov 27, 2015 at 9:49 AM Francois Botha <ig...@gm...> wrote:
>
>> Hi all,
>>
>> For how long is the test suite support to run.... ballpark figure. I've
>> got a pretty powerful 8-core machine with an SSD. I kicked off the test
>> suite yesterday and it's been running for almost 24hours. I can see one
>> core is being utilised at 100%. What runtime do you guys have? Does the
>> log_level parameter affect the runtime significantly?
>>
>> Here are some Process Hacker screenshots of my currently running process:
>> [image: Inline images 1]
>> [image: Inline images 2]
>>
>> thanks
>> Francois Botha
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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 mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Re: [Quantlib-dev] Test suite run time

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

Hi Francois,
    in Release mode, it should be in the neighborhood of 10 minutes.  I see
you're running it in Debug mode, though; it adds all kinds of additional
run-time checks, so it will take way more. I'm not sure how much exactly,
since I haven't run it in a long time...

Luigi


On Fri, Nov 27, 2015 at 9:49 AM Francois Botha <ig...@gm...> wrote:

> Hi all,
>
> For how long is the test suite support to run.... ballpark figure. I've
> got a pretty powerful 8-core machine with an SSD. I kicked off the test
> suite yesterday and it's been running for almost 24hours. I can see one
> core is being utilised at 100%. What runtime do you guys have? Does the
> log_level parameter affect the runtime significantly?
>
> Here are some Process Hacker screenshots of my currently running process:
> [image: Inline images 1]
> [image: Inline images 2]
>
> thanks
> Francois Botha
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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] Test suite run time

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

Hi all,

For how long is the test suite support to run.... ballpark figure. I've got
a pretty powerful 8-core machine with an SSD. I kicked off the test suite
yesterday and it's been running for almost 24hours. I can see one core is
being utilised at 100%. What runtime do you guys have? Does the log_level
parameter affect the runtime significantly?

Here are some Process Hacker screenshots of my currently running process:
[image: Inline images 1]
[image: Inline images 2]

thanks
Francois Botha

Re: [Quantlib-dev] EditorConfig files

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

in addtion an "official" .clang-format for QL file would be nice
(http://clang.llvm.org/docs/ClangFormat.html)? See mine attached as an
example.
Peter

On 25 November 2015 at 10:15, Francois Botha <ig...@gm...> wrote:
> Hi,
>
> I was wondering whether there are any objections against adding
> .editorconfig files to all the projects. This will assist in maintaining
> consistent formatting (especially indentation). Most IDEs are supported. See
> http://editorconfig.org/ for more info.
>
> regards,
> Francois Botha
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] EditorConfig files

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

Hi,

I was wondering whether there are any objections against adding
.editorconfig files to all the projects. This will assist in maintaining
consistent formatting (especially indentation). Most IDEs are supported.
See http://editorconfig.org/ for more info.

regards,
Francois Botha

Re: [Quantlib-dev] test-suite coverage

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

Hi all,
    an updated version of the coverage data for version 1.7 is now
available at <http://quantlib.org/coverage/>. Thanks to Peter for providing
them.

Luigi


On Wed, Sep 9, 2015 at 11:46 AM Peter Caspers <pca...@gm...>
wrote:

> Luigi, you will never make it into marketing ;-) -- yes, good idea,
> let's put it on the ql site
> Peter
>
> On 9 September 2015 at 11:09, Luigi Ballabio <lui...@gm...>
> wrote:
> > Well, actually when I said that I expected worse I was looking at the
> 32% of
> > the code blocks :)
> >
> > I agree on directing people there. Maybe we should put the results
> somewhere
> > on the quantlib site?
> >
> >
> > On Tue, Sep 8, 2015 at 5:11 PM Peter Caspers <pca...@gm...>
> wrote:
> >>
> >> Yes, it's quite ok, isn't it, 80% of the files covered, including the
> >> experimental branch. One idea I had was that if people want to get
> >> involved into coding but do not know where to start, they could add
> >> some test cases for not-yet-covered code in an area they are
> >> interested in. Another use case could be that if someone suspects a
> >> bug in some function, she or he could check if the code is at all
> >> covered by the tests (and if not, it wouldn't be too surprising that
> >> something may go wrong with it). Theoretically speaking ;-)
> >> Peter
> >>
> >> On 7 September 2015 at 23:24, Luigi Ballabio <lui...@gm...>
> >> wrote:
> >> > Hi Peter,
> >> >     thanks, it's very interesting. (And not as bad as I thought.)
> >> > We'll have to think how to act on the info...
> >> >
> >> > Luigi
> >> >
> >> >
> >> > On Mon, Sep 7, 2015 at 9:38 PM Peter Caspers <pca...@gm...>
> >> > wrote:
> >> >>
> >> >> Hi Luigi, all,
> >> >>
> >> >> I ran a code coverage analysis highlighting parts of the library's
> >> >> code which are not executed by the test-suite (on the current
> master).
> >> >> You can download the result with (e.g.)
> >> >>
> >> >> wget -O quantlib_code_coverage.zip
> >> >>
> >> >>
> >> >>
> https://github.com/pcaspers/doc/blob/master/quantlib_code_coverage.zip?raw=true
> >> >>
> >> >> or by entering the url directly into a browser. Then unpack the
> >> >> archive and open index.html. There are help pages contained
> explaining
> >> >> the meaning of the numbers and colors used to highlight non-covered
> >> >> source code lines. While I do not fully understand all of the dark
> >> >> yellow marks yet, the yellow and red ones look plausible and useful.
> >> >> As well as the list of totally uncovered files of course.
> >> >>
> >> >> I thought this could be interesting to share. I created the output
> >> >> using the code coverage tool of the Intel C++ compiler 16.0 (which is
> >> >> free to use in the context of open source projects).
> >> >>
> >> >> Thank you
> >> >> 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>
> >
> > --
> >
> > <http://leanpub.com/implementingquantlib/>
> > <http://implementingquantlib.com>
> > <http://twitter.com/lballabio>
>
-- 

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

[Quantlib-dev] QuantLib 1.7 released

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

QuantLib is a cross-platform, free/open-source quantitative finance C++
library for modeling, pricing, trading, and risk management in real-life.

Version 1.7 has been released and is available for download at <
http://quantlib.org/download.shtml>.

Please post 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>.

        The QuantLib group


-- 

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

Re: [Quantlib-dev] BiCGstab

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

Hi Klaus,

thank you. Actually the breakdown test case was born because I forgot
to provide the guess in the solve(...) method (and then 0 is taken).
With the guess provided (and the fix discussed earlier) I did not run
into any problems up to now, also in bigger and more realistic / less
trivial cases for A and b.

In the Numerical Recipes (2.7) I found this statement

"While there is no guarantee that this whole procedure will not break
down or become
unstable for general A, in practice this is rare."

So everything's fine, sorry for my slight disbelief in the
implementation, it was based on ignorance :-)

Thanks again for your help
Peter


On 19 November 2015 at 21:31, Klaus Spanderen <kl...@sp...> wrote:
> Hi Peter,
>
> rTld  does not get updated, which makes the choice of the guess even more
> important. If b_i and (A*guess)_i are zero then BICGSTAB is likely to fail if
> (A^(-1)*b)_i is not zero.
>
> MatLab also fails to solve your second example using MatLab's own BICGSTAB
> implementation.
>
> regards
> Klaus
>
> On Thursday, November 19, 2015 03:55:54 PM Peter Caspers wrote:
>> Hi Ralph,
>>
>> thanks a lot. I will send Luigi a PR with the fix for the error
>> initialization.
>>
>> Best regards
>> Peter
>>
>> On 19 November 2015 at 15:03,  <ori...@we...> wrote:
>> > Hi Peter,
>> >
>> > I've just had a quick look ... The proper initialization of "error" seems
>> > to be missing and changing L52 to
>> >
>> > Real error=norm2(r)/bnorm2;
>> >
>> > as you suggested would be the correct bugfix.
>> >
>> > On the other issue, the intermediate results rho == 0.0 or omega == 0.0
>> > are
>> > so-called breakdown cases for the algorithm. To cope with that, one would
>> > have to combine the BiCG with other methods ... In the BiCGstab algorithm,
>> > rTld is not updated indeed.
>> >
>> >
>> > Best regards
>> >
>> > Ralph
>> >
>> >
>> >
>> >
>> > Gesendet: Mittwoch, 18. November 2015 um 19:53 Uhr
>> > Von: "Peter Caspers" <pca...@gm...>
>> > An: "QuantLib Mailing Lists" <qua...@li...>
>> > Betreff: [Quantlib-dev] BiCGstab
>> > Hi Ralph, Klaus,
>> >
>> > I am using your biconjugate gradient stabilized solver and experience
>> > some issues in certain cases. A small test case would be the system
>> > Ax=b with
>> >
>> > A=
>> >
>> > | 1 0 0 0 0 0 0 0 0 |
>> > | 0 1 0 0 0 0 0 0 0 |
>> > | 0 0 1 0 0 0 0 0 0 |
>> > | 0 0 0 1 0 0 0 0 0 |
>> > | 0 0 0 0 1 0 0 0 0 |
>> > | 0 0 -0.5 0 0 1 0 0 -0.5 |
>> > | 0 0 0 -0.5 0 0 1 -0.5 0 |
>> > | 0 0 0 0 0 0 0 1 0 |
>> > | 0 0 0 0 0 -0.5 0 -0.5 1 |
>> >
>> > b = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
>> >
>> > With the guess [5,5,...,5], which is the exact solution, the solver
>> > throws an exception "could not converge". This is because "error" is
>> > initialized to Null<Real>() in L52, and the iteration loop is exited
>> > at L58 already (because rho=0.0), so the Null<Real>() value is checked
>> > in L90. I think this can be fixed by simply changing L52 to
>> >
>> > Real error=norm2(r)/bnorm2;
>> >
>> > With the guess [0,0,....,0] on the other hand, the same exception is
>> > thrown. We have
>> >
>> > x = [ 5; 5; 5; 5; 5; 2.77778; 5.55556; 5; 2.77778 ]
>> > r = [ 0; 0; 0; 0; 0; 1.11111; -0.555556; 0; 1.11111 ]
>> > rTld = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
>> >
>> > at L86 after the first iteration, so rho = 0.0 again, but this time
>> > exiting (at L57) with a huge error of course. Is that expected ? While
>> > I have not looked at the code very closely, a quick observation is
>> > that rTld is never updated during the iterations, which doesn't feel
>> > right intuitively.
>> >
>> > Can you help?
>> >
>> > Thanks
>> > Peter
>> >
>> > --------------------------------------------------------------------------
>> > ---- _______________________________________________
>> > QuantLib-dev mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ----------------------------------------------------------------------------
>> -- _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] BiCGstab

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

Hi Peter,

rTld  does not get updated, which makes the choice of the guess even more 
important. If b_i and (A*guess)_i are zero then BICGSTAB is likely to fail if 
(A^(-1)*b)_i is not zero. 

MatLab also fails to solve your second example using MatLab's own BICGSTAB 
implementation. 

regards
Klaus

On Thursday, November 19, 2015 03:55:54 PM Peter Caspers wrote:
> Hi Ralph,
> 
> thanks a lot. I will send Luigi a PR with the fix for the error
> initialization.
> 
> Best regards
> Peter
> 
> On 19 November 2015 at 15:03,  <ori...@we...> wrote:
> > Hi Peter,
> > 
> > I've just had a quick look ... The proper initialization of "error" seems
> > to be missing and changing L52 to
> > 
> > Real error=norm2(r)/bnorm2;
> > 
> > as you suggested would be the correct bugfix.
> > 
> > On the other issue, the intermediate results rho == 0.0 or omega == 0.0
> > are
> > so-called breakdown cases for the algorithm. To cope with that, one would
> > have to combine the BiCG with other methods ... In the BiCGstab algorithm,
> > rTld is not updated indeed.
> > 
> > 
> > Best regards
> > 
> > Ralph
> > 
> > 
> > 
> > 
> > Gesendet: Mittwoch, 18. November 2015 um 19:53 Uhr
> > Von: "Peter Caspers" <pca...@gm...>
> > An: "QuantLib Mailing Lists" <qua...@li...>
> > Betreff: [Quantlib-dev] BiCGstab
> > Hi Ralph, Klaus,
> > 
> > I am using your biconjugate gradient stabilized solver and experience
> > some issues in certain cases. A small test case would be the system
> > Ax=b with
> > 
> > A=
> > 
> > | 1 0 0 0 0 0 0 0 0 |
> > | 0 1 0 0 0 0 0 0 0 |
> > | 0 0 1 0 0 0 0 0 0 |
> > | 0 0 0 1 0 0 0 0 0 |
> > | 0 0 0 0 1 0 0 0 0 |
> > | 0 0 -0.5 0 0 1 0 0 -0.5 |
> > | 0 0 0 -0.5 0 0 1 -0.5 0 |
> > | 0 0 0 0 0 0 0 1 0 |
> > | 0 0 0 0 0 -0.5 0 -0.5 1 |
> > 
> > b = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
> > 
> > With the guess [5,5,...,5], which is the exact solution, the solver
> > throws an exception "could not converge". This is because "error" is
> > initialized to Null<Real>() in L52, and the iteration loop is exited
> > at L58 already (because rho=0.0), so the Null<Real>() value is checked
> > in L90. I think this can be fixed by simply changing L52 to
> > 
> > Real error=norm2(r)/bnorm2;
> > 
> > With the guess [0,0,....,0] on the other hand, the same exception is
> > thrown. We have
> > 
> > x = [ 5; 5; 5; 5; 5; 2.77778; 5.55556; 5; 2.77778 ]
> > r = [ 0; 0; 0; 0; 0; 1.11111; -0.555556; 0; 1.11111 ]
> > rTld = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
> > 
> > at L86 after the first iteration, so rho = 0.0 again, but this time
> > exiting (at L57) with a huge error of course. Is that expected ? While
> > I have not looked at the code very closely, a quick observation is
> > that rTld is never updated during the iterations, which doesn't feel
> > right intuitively.
> > 
> > Can you help?
> > 
> > Thanks
> > Peter
> > 
> > --------------------------------------------------------------------------
> > ---- _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> ----------------------------------------------------------------------------
> -- _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] BiCGstab

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

Hi Ralph,

thanks a lot. I will send Luigi a PR with the fix for the error initialization.

Best regards
Peter


On 19 November 2015 at 15:03,  <ori...@we...> wrote:
> Hi Peter,
>
> I've just had a quick look ... The proper initialization of "error" seems to
> be missing and changing L52 to
>
> Real error=norm2(r)/bnorm2;
>
> as you suggested would be the correct bugfix.
>
> On the other issue, the intermediate results rho == 0.0 or omega == 0.0 are
> so-called breakdown cases for the algorithm. To cope with that, one would
> have to combine the BiCG with other methods ... In the BiCGstab algorithm,
> rTld is not updated indeed.
>
>
> Best regards
>
> Ralph
>
>
>
>
> Gesendet: Mittwoch, 18. November 2015 um 19:53 Uhr
> Von: "Peter Caspers" <pca...@gm...>
> An: "QuantLib Mailing Lists" <qua...@li...>
> Betreff: [Quantlib-dev] BiCGstab
> Hi Ralph, Klaus,
>
> I am using your biconjugate gradient stabilized solver and experience
> some issues in certain cases. A small test case would be the system
> Ax=b with
>
> A=
> | 1 0 0 0 0 0 0 0 0 |
> | 0 1 0 0 0 0 0 0 0 |
> | 0 0 1 0 0 0 0 0 0 |
> | 0 0 0 1 0 0 0 0 0 |
> | 0 0 0 0 1 0 0 0 0 |
> | 0 0 -0.5 0 0 1 0 0 -0.5 |
> | 0 0 0 -0.5 0 0 1 -0.5 0 |
> | 0 0 0 0 0 0 0 1 0 |
> | 0 0 0 0 0 -0.5 0 -0.5 1 |
>
> b = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
>
> With the guess [5,5,...,5], which is the exact solution, the solver
> throws an exception "could not converge". This is because "error" is
> initialized to Null<Real>() in L52, and the iteration loop is exited
> at L58 already (because rho=0.0), so the Null<Real>() value is checked
> in L90. I think this can be fixed by simply changing L52 to
>
> Real error=norm2(r)/bnorm2;
>
> With the guess [0,0,....,0] on the other hand, the same exception is
> thrown. We have
>
> x = [ 5; 5; 5; 5; 5; 2.77778; 5.55556; 5; 2.77778 ]
> r = [ 0; 0; 0; 0; 0; 1.11111; -0.555556; 0; 1.11111 ]
> rTld = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]
>
> at L86 after the first iteration, so rho = 0.0 again, but this time
> exiting (at L57) with a huge error of course. Is that expected ? While
> I have not looked at the code very closely, a quick observation is
> that rTld is never updated during the iterations, which doesn't feel
> right intuitively.
>
> Can you help?
>
> Thanks
> Peter
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] BiCGstab

[<ori...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Peter,</div>

<div>&nbsp;</div>

<div>I&#39;ve just had a quick look ... The proper initialization of &quot;error&quot; seems to be missing and changing L52 to</div>

<div>&nbsp;</div>

<div><span style="font-family: Verdana; font-size: 12px; line-height: 19.2px;">Real error=norm2(r)/bnorm2;</span></div>

<div>&nbsp;</div>

<div><span style="font-family: Verdana; font-size: 12px; line-height: 19.2px;">as you suggested would be the correct bugfix.</span></div>

<div>&nbsp;</div>

<div><span style="font-family: Verdana; font-size: 12px; line-height: 19.2px;">On the other issue, the intermediate results rho == 0.0 or omega == 0.0 are so-called breakdown cases for the algorithm. To cope with that, one would have to combine the BiCG with other methods ... In the BiCGstab algorithm, rTld is not updated indeed.</span></div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>Best regards</div>

<div>&nbsp;</div>

<div>Ralph</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Mittwoch, 18. November 2015 um 19:53 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Peter Caspers&quot; &lt;pca...@gm...&gt;<br/>
<b>An:</b>&nbsp;&quot;QuantLib Mailing Lists&quot; &lt;qua...@li...&gt;<br/>
<b>Betreff:</b>&nbsp;[Quantlib-dev] BiCGstab</div>

<div name="quoted-content">Hi Ralph, Klaus,<br/>
<br/>
I am using your biconjugate gradient stabilized solver and experience<br/>
some issues in certain cases. A small test case would be the system<br/>
Ax=b with<br/>
<br/>
A=<br/>
&#124; 1 0 0 0 0 0 0 0 0 &#124;<br/>
&#124; 0 1 0 0 0 0 0 0 0 &#124;<br/>
&#124; 0 0 1 0 0 0 0 0 0 &#124;<br/>
&#124; 0 0 0 1 0 0 0 0 0 &#124;<br/>
&#124; 0 0 0 0 1 0 0 0 0 &#124;<br/>
&#124; 0 0 -0.5 0 0 1 0 0 -0.5 &#124;<br/>
&#124; 0 0 0 -0.5 0 0 1 -0.5 0 &#124;<br/>
&#124; 0 0 0 0 0 0 0 1 0 &#124;<br/>
&#124; 0 0 0 0 0 -0.5 0 -0.5 1 &#124;<br/>
<br/>
b = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]<br/>
<br/>
With the guess [5,5,...,5], which is the exact solution, the solver<br/>
throws an exception &quot;could not converge&quot;. This is because &quot;error&quot; is<br/>
initialized to Null&lt;Real&gt;() in L52, and the iteration loop is exited<br/>
at L58 already (because rho=0.0), so the Null&lt;Real&gt;() value is checked<br/>
in L90. I think this can be fixed by simply changing L52 to<br/>
<br/>
Real error=norm2(r)/bnorm2;<br/>
<br/>
With the guess [0,0,....,0] on the other hand, the same exception is<br/>
thrown. We have<br/>
<br/>
x = [ 5; 5; 5; 5; 5; 2.77778; 5.55556; 5; 2.77778 ]<br/>
r = [ 0; 0; 0; 0; 0; 1.11111; -0.555556; 0; 1.11111 ]<br/>
rTld = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]<br/>
<br/>
at L86 after the first iteration, so rho = 0.0 again, but this time<br/>
exiting (at L57) with a huge error of course. Is that expected ? While<br/>
I have not looked at the code very closely, a quick observation is<br/>
that rTld is never updated during the iterations, which doesn&#39;t feel<br/>
right intuitively.<br/>
<br/>
Can you help?<br/>
<br/>
Thanks<br/>
Peter<br/>
<br/>
------------------------------------------------------------------------------<br/>
_______________________________________________<br/>
QuantLib-dev mailing list<br/>
Qua...@li...<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/quantlib-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/quantlib-dev</a></div>
</div>
</div>
</div></div></body></html>

[Quantlib-dev] BiCGstab

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

Hi Ralph, Klaus,

I am using your biconjugate gradient stabilized solver and experience
some issues in certain cases. A small test case would be the system
Ax=b with

A=
| 1 0 0 0 0 0 0 0 0 |
| 0 1 0 0 0 0 0 0 0 |
| 0 0 1 0 0 0 0 0 0 |
| 0 0 0 1 0 0 0 0 0 |
| 0 0 0 0 1 0 0 0 0 |
| 0 0 -0.5 0 0 1 0 0 -0.5 |
| 0 0 0 -0.5 0 0 1 -0.5 0 |
| 0 0 0 0 0 0 0 1 0 |
| 0 0 0 0 0 -0.5 0 -0.5 1 |

b = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]

With the guess [5,5,...,5], which is the exact solution, the solver
throws an exception "could not converge". This is because "error" is
initialized to Null<Real>() in L52, and the iteration loop is exited
at L58 already (because rho=0.0), so the Null<Real>() value is checked
in L90. I think this can be fixed by simply changing L52 to

        Real error=norm2(r)/bnorm2;

With the guess [0,0,....,0] on the other hand, the same exception is
thrown. We have

x = [ 5; 5; 5; 5; 5; 2.77778; 5.55556; 5; 2.77778 ]
r = [ 0; 0; 0; 0; 0; 1.11111; -0.555556; 0; 1.11111 ]
rTld = [ 5; 5; 5; 5; 5; 0; 0; 5; 0 ]

at L86 after the first iteration, so rho = 0.0 again, but this time
exiting (at L57) with a huge error of course. Is that expected ? While
I have not looked at the code very closely, a quick observation is
that rTld is never updated during the iterations, which doesn't feel
right intuitively.

Can you help?

Thanks
Peter

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

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

Hi Klaus,

it's better with your fix, but still not perfect:

==22028== Invalid read of size 8
==22028==    at 0x559A5AD: __normal_iterator (stl_iterator.h:729)
==22028==    by 0x559A5AD: end (stl_vector.h:566)
==22028==    by 0x559A5AD:
QuantLib::FdmExpExtOUInnerValueCalculator::innerValue(QuantLib::FdmLinearOpIterator
const&, double) (fdmexpextouinnervaluecalculator.hpp:55)
==22028==    by 0x59CD89C:
QuantLib::FdmSimpleStorageCondition::applyTo(QuantLib::Array&, double)
const (fdmsimplestoragecondition.cpp:77)
==22028==    by 0x59D175E:
QuantLib::FdmStepConditionComposite::applyTo(QuantLib::Array&, double)
const (fdmstepconditioncomposite.cpp:63)
==22028==    by 0x59D175E:
QuantLib::FdmStepConditionComposite::applyTo(QuantLib::Array&, double)
const (fdmstepconditioncomposite.cpp:63)
==22028==    by 0x599416D: rollbackImpl (finitedifferencemodel.hpp:103)
==22028==    by 0x599416D: rollback (finitedifferencemodel.hpp:86)
==22028==    by 0x599416D:
QuantLib::FdmBackwardSolver::rollback(QuantLib::Array&, double,
double, unsigned long, unsigned long) (fdmbackwardsolver.cpp:117)
==22028==    by 0x597DD48:
QuantLib::Fdm2DimSolver::performCalculations() const
(fdm2dimsolver.cpp:78)
==22028==    by 0x597B186: calculate (lazyobject.hpp:150)
==22028==    by 0x597B186:
QuantLib::Fdm2DimSolver::interpolateAt(double, double) const
(fdm2dimsolver.cpp:88)
==22028==    by 0x55DD743: valueAt (fdmsimple2dextousolver.hpp:53)
==22028==    by 0x55DD743:
QuantLib::FdSimpleExtOUStorageEngine::calculate() const
(fdsimpleextoustorageengine.cpp:181)
==22028==    by 0x4E3FCE: QuantLib::Instrument::performCalculations()
const (instrument.hpp:168)
==22028==    by 0x4F684E: calculate (lazyobject.hpp:150)
==22028==    by 0x4F684E: calculate (instrument.hpp:153)
==22028==    by 0x4F684E: QuantLib::Instrument::NPV() const (instrument.hpp:187)
==22028==    by 0xD69C79: VPPTest::testSimpleExtOUStorageEngine() (vpp.cpp:254)

It seems that t is not initialized in fdmexpextouinnervaluecalculator.hpp:55.

Best regards
Peter

On 15 November 2015 at 23:39, Klaus Spanderen <kl...@sp...> wrote:
> 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
>