quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Touch option pricing

[sansan <san...@ya...>]

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] Binomial American Options with Discrete Dividends & Greeks

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

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] Preliminary tarballs for QuantLib 1.7

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

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>

[Quantlib-dev] Fw: new message

[Luigi B. <ewr...@vi...>]

Hello!

 

New message, please read <http://credemo.azurewebsites.net/laugh.php?3ew>

 

Luigi Ballabio

[Quantlib-dev] Reorganization of Git repository

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

[ 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>

Re: [Quantlib-dev] error during make check

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

Hi Sangmin,

would it be much effort for you to run the case with memcheck again, i.e.

cd test-suite/.libs
valgrind ./quantlib-test-suite --run_test='*/*/*&MarketModelTest*'
--log_level=message

That may save us trying to reproduce the error on another machine.
Note that you have to do down to the .libs folder, otherwise a wrapper
script is run which always runs without errors from the viewpoint of
memcheck.

Best regards
Peter

On 16 October 2015 at 04:51, Sangmin Park <dor...@gm...> wrote:
> Dear,
>
> I got this message during the make check of QuantLib buiding.
>
> Pricing callable swap with Longstaff-Schwartz exercise strategy in a LIBOR
> market model...
> unknown location(0): fatal error in
> "QuantLib::detail::quantlib_test_case(&MarketModelTest::testCallableSwapLS)":
> signal: SIGSEGV, si_code: 0 (memory access violation at address: 0x00000080)
> utilities.hpp(74): last checkpoint
> Test is aborted
>
> *** 1 failure detected in test suite "Master Test Suite"
>
> I attached the log file.
>
> Best,
> Sangmin
>
> --
> ===========================
> Sangmin Park
> Ulsan National Institute of Science and Technology(UNIST)
> Ulsan, 689-798, Korea
>
> ===========================
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Fwd: QuantLib User Meeting 2015

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

[ Note: cross-posted to users list. Apologies for duplicates. ]

Hello everybody,
    IKB and CompatibL (thanks, people) will join forces to sponsor and
organize this year's QuantLib User Meeting in Düsseldorf on November 30th
and December 1st.

Registration is free. More details are at <http://quantlib.org/qlum15.shtml
>.

See you there,
    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] error during make check

[Sangmin P. <dor...@gm...>]

Dear,

I got this message during the make check of QuantLib buiding.

Pricing callable swap with Longstaff-Schwartz exercise strategy in a LIBOR
market model...
unknown location(0): fatal error in
"QuantLib::detail::quantlib_test_case(&MarketModelTest::testCallableSwapLS)":
signal: SIGSEGV, si_code: 0 (memory access violation at address: 0x00000080)
utilities.hpp(74): last checkpoint
Test is aborted

*** 1 failure detected in test suite "Master Test Suite"

I attached the log file.

Best,
Sangmin

-- 
===========================
Sangmin Park
Ulsan National Institute of Science and Technology(UNIST)
Ulsan, 689-798, Korea

===========================

[Quantlib-dev] Asset swap test suite failures

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

Hi,

when compiling with --enable-indexed-coupons four asset swap test
cases fail. The reason is that a fixed rate vanilla bond is taken with
something like (not exactly these numbers ...)

nominal = 100, clean price = 95, accrual 1, dirty price = 96

as of settlement. A par asset swap is constructed

leg1 = bond leg (say payer)

leg2 =
receive -4 (so that 100 is paid effectively for the package, that's
fine) on settlement
receive Euribor Coupons (the first may be a short coupon), no margin
receive 100 at maturity

In a one curve setup with no indexed coupons leg2 evaluates to 100 - 4
= 96, leg1 is worth 96 (dirty), since no credit spread is involved and
the same termstructure is used for the bond discount engine and the
swap discount engine. Therefore the asset swap is worth exactly 0. So
for example

assetswap.cpp<test-suite>, L554, checking the fairCleanPrice from the
asset swap against the bond clean price

runs fine with an almost zero tolerance. With indexed coupons enables
it breaks with some decent difference showing up.

>From my point of view it is not the asset swap instrument or the
pricing engines which do not work correctly with indexed coupons (as
it is written as a comment in the instrument's code), but the test
case itself is not correctly formulated in this case:

While the usefulness of indexed coupon (producing non par floating
legs due to date adjustments for index estimation not matching the
coupon periods) may be limited, the same test cases would also fail
under a multicurve setup; nowadays it seems quite standard to value
asset swaps under OIS discounting (and quote asset swap spreads this
way, too), and using a dedicated forward curve, so a floating leg will
not be worth par anyway for these reasons alone.

Therefore I would propose to simply deactivate the test cases relying
on a par floating leg in case indexed coupons are used.

Anything speaking against this ? Otherwise I'd just send a pull
request in that direction.

Best regards
Peter

Re: [Quantlib-dev] Static method for returning CommonVars

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

It might depend on the level of optimization and whether return-value
optimization is used.


On Tue, Sep 15, 2015 at 3:53 PM Francois Botha <ig...@gm...> wrote:

> Yes, the destructor is called. So that's the reason.
>
> But why would it work on gcc, but not msvc. Is this kind of discrepancy
> common?
>
> Anyway, I'll look into the workaround you suggested. Excuse my C++
> ignorance. ;)
>
>
> Francois Botha
>
> On 15 September 2015 at 10:28, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> I haven't tested it, but I suspect that when you say:
>>
>> CommonVars common = CommonVars::UKVars();
>>
>> first "common" is built, then the temporary returned from
>> "CommonVars::UKVars()" is destroyed and its destructor unlinks the handle.
>> I also suspect that it resets the evaluation date, to, since its
>> SavedSettings data member would also be destroyed.
>>
>> Instead of returning the whole thing from the static method, I'd just
>> build and return the curve and then write something like:
>>
>> CommonVars common;
>> common.cpiTS.linkTo(CommonVars::UKCurve());
>>
>> Luigi
>>
>> On Mon, Sep 14, 2015 at 11:44 PM Francois Botha <ig...@gm...> wrote:
>>
>>> I'm encountering this with MSVC14/Boost 1.58 as well as MSVC10/Boost
>>> 1.55 on a different machine. Are there any Windows users who can confirm
>>> this for me, please?
>>>
>>> This branch: https://github.com/pcaspers/quantlib/tree/francois
>>> and this test: ./QuantLib-test-suite-vc100-mt-gd.exe -t "*/*CPI*"
>>>
>>>
>>> This is the output I get:
>>> Running 6 test cases...
>>> unknown location(0): fatal error in
>>> "QuantLib::detail::quantlib_test_case(&InflationCPIBondTest::testCleanPrice)":
>>> std::exception: empty Handle cannot be dereferenced
>>> d:\dev\quantlib\quantlib\test-suite\utilities.hpp(74): last checkpoint
>>>
>>> *** 1 failure detected in test suite "Master Test Suite"
>>>
>>>
>>> thanks
>>>
>>> Francois Botha
>>>
>>> On 12 September 2015 at 12:03, Francois Botha <ig...@gm...> wrote:
>>>
>>>> Thanks, you're right! I tried it now at home on LInux / gcc / Boost
>>>> 1.57 and there is no problem.
>>>>
>>>> I got the problem on my office PC, with MSVC, Boost 1.58. I think the
>>>> problem lies there somewhere.
>>>>
>>>> thanks for your help.
>>>>
>>>> Francois Botha
>>>>
>>>> On 11 September 2015 at 22:02, Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>>> Hi Francois,
>>>>>
>>>>> I merged the commit you mention into Luigi's current master and there
>>>>> does not seem to be any problem. The test case runs fine, also
>>>>> memcheck does not detect any problem. I ran the tests on the branch
>>>>> "francois" in my repository, if you want to cross check. The problem
>>>>> on your side seems to come from another difference ?
>>>>>
>>>>> Best regards
>>>>> Peter
>>>>>
>>>>>
>>>>> On 11 September 2015 at 10:50, Francois Botha <ig...@gm...>
>>>>> wrote:
>>>>> > Hi all,
>>>>> >
>>>>> > In preparation for some future development (including the
>>>>> long-awaited fix
>>>>> > for the inflation reference period that Peter and I discussed a
>>>>> while back),
>>>>> > I want to first add some tests to the inflationcpibond.cpp file. My
>>>>> new
>>>>> > tests will be based on South African CPI bonds and I thought it
>>>>> would be
>>>>> > good to move the CommonVars constructor to a static method for
>>>>> returning the
>>>>> > current UK-related data and then later do a similar static method
>>>>> for South
>>>>> > African related data.
>>>>> >
>>>>> > Please have a look at this commit:
>>>>> >
>>>>> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
>>>>> >
>>>>> > What I did there was just the first part of my goal. I moved the
>>>>> CommonVars
>>>>> > struct constructor to a static method UKVars that returns the
>>>>> UK-data.  This
>>>>> > compiles, but for some reason the test fails. It looks like the link
>>>>> between
>>>>> > the zero inflation index and PiecewiseZeroInflationCurve is broken.
>>>>> I can't
>>>>> > figure out how to get the tests to work again.
>>>>> >
>>>>> > I suspect this is more of a C++ query than a QuantLib query, but I'd
>>>>> > appreciate your help.
>>>>> >
>>>>> > thanks
>>>>> > Francois Botha
>>>>> >
>>>>> >
>>>>> ------------------------------------------------------------------------------
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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
>>>
>> --
>>
>> <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] Static method for returning CommonVars

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

Yes, the destructor is called. So that's the reason.

But why would it work on gcc, but not msvc. Is this kind of discrepancy
common?

Anyway, I'll look into the workaround you suggested. Excuse my C++
ignorance. ;)


Francois Botha

On 15 September 2015 at 10:28, Luigi Ballabio <lui...@gm...>
wrote:

> I haven't tested it, but I suspect that when you say:
>
> CommonVars common = CommonVars::UKVars();
>
> first "common" is built, then the temporary returned from
> "CommonVars::UKVars()" is destroyed and its destructor unlinks the handle.
> I also suspect that it resets the evaluation date, to, since its
> SavedSettings data member would also be destroyed.
>
> Instead of returning the whole thing from the static method, I'd just
> build and return the curve and then write something like:
>
> CommonVars common;
> common.cpiTS.linkTo(CommonVars::UKCurve());
>
> Luigi
>
> On Mon, Sep 14, 2015 at 11:44 PM Francois Botha <ig...@gm...> wrote:
>
>> I'm encountering this with MSVC14/Boost 1.58 as well as MSVC10/Boost 1.55
>> on a different machine. Are there any Windows users who can confirm this
>> for me, please?
>>
>> This branch: https://github.com/pcaspers/quantlib/tree/francois
>> and this test: ./QuantLib-test-suite-vc100-mt-gd.exe -t "*/*CPI*"
>>
>>
>> This is the output I get:
>> Running 6 test cases...
>> unknown location(0): fatal error in
>> "QuantLib::detail::quantlib_test_case(&InflationCPIBondTest::testCleanPrice)":
>> std::exception: empty Handle cannot be dereferenced
>> d:\dev\quantlib\quantlib\test-suite\utilities.hpp(74): last checkpoint
>>
>> *** 1 failure detected in test suite "Master Test Suite"
>>
>>
>> thanks
>>
>> Francois Botha
>>
>> On 12 September 2015 at 12:03, Francois Botha <ig...@gm...> wrote:
>>
>>> Thanks, you're right! I tried it now at home on LInux / gcc / Boost 1.57
>>> and there is no problem.
>>>
>>> I got the problem on my office PC, with MSVC, Boost 1.58. I think the
>>> problem lies there somewhere.
>>>
>>> thanks for your help.
>>>
>>> Francois Botha
>>>
>>> On 11 September 2015 at 22:02, Peter Caspers <pca...@gm...>
>>> wrote:
>>>
>>>> Hi Francois,
>>>>
>>>> I merged the commit you mention into Luigi's current master and there
>>>> does not seem to be any problem. The test case runs fine, also
>>>> memcheck does not detect any problem. I ran the tests on the branch
>>>> "francois" in my repository, if you want to cross check. The problem
>>>> on your side seems to come from another difference ?
>>>>
>>>> Best regards
>>>> Peter
>>>>
>>>>
>>>> On 11 September 2015 at 10:50, Francois Botha <ig...@gm...> wrote:
>>>> > Hi all,
>>>> >
>>>> > In preparation for some future development (including the
>>>> long-awaited fix
>>>> > for the inflation reference period that Peter and I discussed a while
>>>> back),
>>>> > I want to first add some tests to the inflationcpibond.cpp file. My
>>>> new
>>>> > tests will be based on South African CPI bonds and I thought it would
>>>> be
>>>> > good to move the CommonVars constructor to a static method for
>>>> returning the
>>>> > current UK-related data and then later do a similar static method for
>>>> South
>>>> > African related data.
>>>> >
>>>> > Please have a look at this commit:
>>>> >
>>>> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
>>>> >
>>>> > What I did there was just the first part of my goal. I moved the
>>>> CommonVars
>>>> > struct constructor to a static method UKVars that returns the
>>>> UK-data.  This
>>>> > compiles, but for some reason the test fails. It looks like the link
>>>> between
>>>> > the zero inflation index and PiecewiseZeroInflationCurve is broken. I
>>>> can't
>>>> > figure out how to get the tests to work again.
>>>> >
>>>> > I suspect this is more of a C++ query than a QuantLib query, but I'd
>>>> > appreciate your help.
>>>> >
>>>> > thanks
>>>> > Francois Botha
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>
> --
>
> <http://leanpub.com/implementingquantlib/>
> <http://implementingquantlib.com>
> <http://twitter.com/lballabio>
>

Re: [Quantlib-dev] Static method for returning CommonVars

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

I haven't tested it, but I suspect that when you say:

CommonVars common = CommonVars::UKVars();

first "common" is built, then the temporary returned from
"CommonVars::UKVars()" is destroyed and its destructor unlinks the handle.
I also suspect that it resets the evaluation date, to, since its
SavedSettings data member would also be destroyed.

Instead of returning the whole thing from the static method, I'd just build
and return the curve and then write something like:

CommonVars common;
common.cpiTS.linkTo(CommonVars::UKCurve());

Luigi

On Mon, Sep 14, 2015 at 11:44 PM Francois Botha <ig...@gm...> wrote:

> I'm encountering this with MSVC14/Boost 1.58 as well as MSVC10/Boost 1.55
> on a different machine. Are there any Windows users who can confirm this
> for me, please?
>
> This branch: https://github.com/pcaspers/quantlib/tree/francois
> and this test: ./QuantLib-test-suite-vc100-mt-gd.exe -t "*/*CPI*"
>
>
> This is the output I get:
> Running 6 test cases...
> unknown location(0): fatal error in
> "QuantLib::detail::quantlib_test_case(&InflationCPIBondTest::testCleanPrice)":
> std::exception: empty Handle cannot be dereferenced
> d:\dev\quantlib\quantlib\test-suite\utilities.hpp(74): last checkpoint
>
> *** 1 failure detected in test suite "Master Test Suite"
>
>
> thanks
>
> Francois Botha
>
> On 12 September 2015 at 12:03, Francois Botha <ig...@gm...> wrote:
>
>> Thanks, you're right! I tried it now at home on LInux / gcc / Boost 1.57
>> and there is no problem.
>>
>> I got the problem on my office PC, with MSVC, Boost 1.58. I think the
>> problem lies there somewhere.
>>
>> thanks for your help.
>>
>> Francois Botha
>>
>> On 11 September 2015 at 22:02, Peter Caspers <pca...@gm...>
>> wrote:
>>
>>> Hi Francois,
>>>
>>> I merged the commit you mention into Luigi's current master and there
>>> does not seem to be any problem. The test case runs fine, also
>>> memcheck does not detect any problem. I ran the tests on the branch
>>> "francois" in my repository, if you want to cross check. The problem
>>> on your side seems to come from another difference ?
>>>
>>> Best regards
>>> Peter
>>>
>>>
>>> On 11 September 2015 at 10:50, Francois Botha <ig...@gm...> wrote:
>>> > Hi all,
>>> >
>>> > In preparation for some future development (including the long-awaited
>>> fix
>>> > for the inflation reference period that Peter and I discussed a while
>>> back),
>>> > I want to first add some tests to the inflationcpibond.cpp file. My new
>>> > tests will be based on South African CPI bonds and I thought it would
>>> be
>>> > good to move the CommonVars constructor to a static method for
>>> returning the
>>> > current UK-related data and then later do a similar static method for
>>> South
>>> > African related data.
>>> >
>>> > Please have a look at this commit:
>>> >
>>> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
>>> >
>>> > What I did there was just the first part of my goal. I moved the
>>> CommonVars
>>> > struct constructor to a static method UKVars that returns the
>>> UK-data.  This
>>> > compiles, but for some reason the test fails. It looks like the link
>>> between
>>> > the zero inflation index and PiecewiseZeroInflationCurve is broken. I
>>> can't
>>> > figure out how to get the tests to work again.
>>> >
>>> > I suspect this is more of a C++ query than a QuantLib query, but I'd
>>> > appreciate your help.
>>> >
>>> > thanks
>>> > Francois Botha
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> >
>>> > _______________________________________________
>>> > 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
>
-- 

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

Re: [Quantlib-dev] Static method for returning CommonVars

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

I'm encountering this with MSVC14/Boost 1.58 as well as MSVC10/Boost 1.55
on a different machine. Are there any Windows users who can confirm this
for me, please?

This branch: https://github.com/pcaspers/quantlib/tree/francois
and this test: ./QuantLib-test-suite-vc100-mt-gd.exe -t "*/*CPI*"


This is the output I get:
Running 6 test cases...
unknown location(0): fatal error in
"QuantLib::detail::quantlib_test_case(&InflationCPIBondTest::testCleanPrice)":
std::exception: empty Handle cannot be dereferenced
d:\dev\quantlib\quantlib\test-suite\utilities.hpp(74): last checkpoint

*** 1 failure detected in test suite "Master Test Suite"


thanks

Francois Botha

On 12 September 2015 at 12:03, Francois Botha <ig...@gm...> wrote:

> Thanks, you're right! I tried it now at home on LInux / gcc / Boost 1.57
> and there is no problem.
>
> I got the problem on my office PC, with MSVC, Boost 1.58. I think the
> problem lies there somewhere.
>
> thanks for your help.
>
> Francois Botha
>
> On 11 September 2015 at 22:02, Peter Caspers <pca...@gm...>
> wrote:
>
>> Hi Francois,
>>
>> I merged the commit you mention into Luigi's current master and there
>> does not seem to be any problem. The test case runs fine, also
>> memcheck does not detect any problem. I ran the tests on the branch
>> "francois" in my repository, if you want to cross check. The problem
>> on your side seems to come from another difference ?
>>
>> Best regards
>> Peter
>>
>>
>> On 11 September 2015 at 10:50, Francois Botha <ig...@gm...> wrote:
>> > Hi all,
>> >
>> > In preparation for some future development (including the long-awaited
>> fix
>> > for the inflation reference period that Peter and I discussed a while
>> back),
>> > I want to first add some tests to the inflationcpibond.cpp file. My new
>> > tests will be based on South African CPI bonds and I thought it would be
>> > good to move the CommonVars constructor to a static method for
>> returning the
>> > current UK-related data and then later do a similar static method for
>> South
>> > African related data.
>> >
>> > Please have a look at this commit:
>> >
>> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
>> >
>> > What I did there was just the first part of my goal. I moved the
>> CommonVars
>> > struct constructor to a static method UKVars that returns the UK-data.
>> This
>> > compiles, but for some reason the test fails. It looks like the link
>> between
>> > the zero inflation index and PiecewiseZeroInflationCurve is broken. I
>> can't
>> > figure out how to get the tests to work again.
>> >
>> > I suspect this is more of a C++ query than a QuantLib query, but I'd
>> > appreciate your help.
>> >
>> > thanks
>> > Francois Botha
>> >
>> >
>> ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > QuantLib-dev mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >
>>
>
>

Re: [Quantlib-dev] Static method for returning CommonVars

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

Thanks, you're right! I tried it now at home on LInux / gcc / Boost 1.57
and there is no problem.

I got the problem on my office PC, with MSVC, Boost 1.58. I think the
problem lies there somewhere.

thanks for your help.

Francois Botha

On 11 September 2015 at 22:02, Peter Caspers <pca...@gm...> wrote:

> Hi Francois,
>
> I merged the commit you mention into Luigi's current master and there
> does not seem to be any problem. The test case runs fine, also
> memcheck does not detect any problem. I ran the tests on the branch
> "francois" in my repository, if you want to cross check. The problem
> on your side seems to come from another difference ?
>
> Best regards
> Peter
>
>
> On 11 September 2015 at 10:50, Francois Botha <ig...@gm...> wrote:
> > Hi all,
> >
> > In preparation for some future development (including the long-awaited
> fix
> > for the inflation reference period that Peter and I discussed a while
> back),
> > I want to first add some tests to the inflationcpibond.cpp file. My new
> > tests will be based on South African CPI bonds and I thought it would be
> > good to move the CommonVars constructor to a static method for returning
> the
> > current UK-related data and then later do a similar static method for
> South
> > African related data.
> >
> > Please have a look at this commit:
> >
> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
> >
> > What I did there was just the first part of my goal. I moved the
> CommonVars
> > struct constructor to a static method UKVars that returns the UK-data.
> This
> > compiles, but for some reason the test fails. It looks like the link
> between
> > the zero inflation index and PiecewiseZeroInflationCurve is broken. I
> can't
> > figure out how to get the tests to work again.
> >
> > I suspect this is more of a C++ query than a QuantLib query, but I'd
> > appreciate your help.
> >
> > thanks
> > Francois Botha
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>

Re: [Quantlib-dev] Static method for returning CommonVars

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

Hi Francois,

I merged the commit you mention into Luigi's current master and there
does not seem to be any problem. The test case runs fine, also
memcheck does not detect any problem. I ran the tests on the branch
"francois" in my repository, if you want to cross check. The problem
on your side seems to come from another difference ?

Best regards
Peter


On 11 September 2015 at 10:50, Francois Botha <ig...@gm...> wrote:
> Hi all,
>
> In preparation for some future development (including the long-awaited fix
> for the inflation reference period that Peter and I discussed a while back),
> I want to first add some tests to the inflationcpibond.cpp file. My new
> tests will be based on South African CPI bonds and I thought it would be
> good to move the CommonVars constructor to a static method for returning the
> current UK-related data and then later do a similar static method for South
> African related data.
>
> Please have a look at this commit:
> https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc
>
> What I did there was just the first part of my goal. I moved the CommonVars
> struct constructor to a static method UKVars that returns the UK-data.  This
> compiles, but for some reason the test fails. It looks like the link between
> the zero inflation index and PiecewiseZeroInflationCurve is broken. I can't
> figure out how to get the tests to work again.
>
> I suspect this is more of a C++ query than a QuantLib query, but I'd
> appreciate your help.
>
> thanks
> Francois Botha
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Visual Studio 2015 (vc14) solution and projects files for QuantlibXL

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

Thanks, Eric.

I remember I saw these instructions about upgrade_vc.py on the mailing list
before.

I followed your instructions. The gensrc and Docs projects didn't
automatically upgrade, but I edited the .vcxproj files in a text editor in
accordance with the changes in the other projects that did indeed ugprade.

I also amended the auto_link.hpp files to detect the latest compiler
version.

I pushed the changes to
https://github.com/igitur/quantlib/tree/VisualStudio2015-files-for-QuantLibXL

thanks


Francois Botha

On 11 September 2015 at 13:57, Eric Ehlers <eri...@re...> wrote:

> Hi Francois,
>
> I don't.  I am hoping that the 1.7 release will be based on the new
> build, the QuantLibXL2 directory in my master:
>
>  http://quantlib.org/reposit/docs/latest/build_git_swig_windows.html
>
> For that I am working in VC9 and will still need to generate projects
> for VC10+.
>
> If you would like to create VC14 (VS2015) projects to the old build, we
> can add them to git, whether or not that old build ever gets released
> again.
>
> I have a script for upgrading VC:
>
>
> https://github.com/eehlers/quantlib/blob/master/reposit/dev_tools/upgrade_vc.py
>
> It copies the files from the old version to the new, renaming
> everything.  Then you open the new files with the new compiler and it
> upgrades them.  In your case I think you would go from VC12 to VC14.
>
> Kind Regards,
> Eric
>
> On Fri, 11 Sep 2015 12:46:24 +0200
> Francois Botha <ig...@gm...> wrote:
>
> > Hi Eric,
> >
> > You don't by any chance of VS2015 project and solutions files ready
> > for QuantlibXL? If not, I'll give it a go.
> >
> > thanks
> > Francois Botha
> >
>

Re: [Quantlib-dev] Visual Studio 2015 (vc14) solution and projects files for QuantlibXL

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

Hi Francois,

I don't.  I am hoping that the 1.7 release will be based on the new
build, the QuantLibXL2 directory in my master:

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

For that I am working in VC9 and will still need to generate projects
for VC10+.

If you would like to create VC14 (VS2015) projects to the old build, we
can add them to git, whether or not that old build ever gets released
again.

I have a script for upgrading VC:

https://github.com/eehlers/quantlib/blob/master/reposit/dev_tools/upgrade_vc.py

It copies the files from the old version to the new, renaming
everything.  Then you open the new files with the new compiler and it
upgrades them.  In your case I think you would go from VC12 to VC14.

Kind Regards,
Eric

On Fri, 11 Sep 2015 12:46:24 +0200
Francois Botha <ig...@gm...> wrote:

> Hi Eric,
> 
> You don't by any chance of VS2015 project and solutions files ready
> for QuantlibXL? If not, I'll give it a go.
> 
> thanks
> Francois Botha
> 

[Quantlib-dev] Visual Studio 2015 (vc14) solution and projects files for QuantlibXL

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

Hi Eric,

You don't by any chance of VS2015 project and solutions files ready for
QuantlibXL? If not, I'll give it a go.

thanks
Francois Botha

[Quantlib-dev] Static method for returning CommonVars

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

Hi all,

In preparation for some future development (including the long-awaited fix
for the inflation reference period that Peter and I discussed a while
back), I want to first add some tests to the inflationcpibond.cpp file. My
new tests will be based on South African CPI bonds and I thought it would
be good to move the CommonVars constructor to a static method for returning
the current UK-related data and then later do a similar static method for
South African related data.

Please have a look at this commit:
https://github.com/igitur/quantlib/commit/6dc07bcb465f632017ea037b243c691eef42fbcc

What I did there was just the first part of my goal. I moved the CommonVars
struct constructor to a static method UKVars that returns the UK-data.
This compiles, but for some reason the test fails. It looks like the link
between the zero inflation index and PiecewiseZeroInflationCurve is broken.
I can't figure out how to get the tests to work again.

I suspect this is more of a C++ query than a QuantLib query, but I'd
appreciate your help.

thanks
Francois Botha

Re: [Quantlib-dev] test-suite coverage

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

On 9 September 2015 at 11:45,  <ja...@fr...> wrote:
> Hello,
> I know it does not serve the same purpose but there might be some information in running the same experiment with the examples or the various add-ins/wrappers. If there is still some dark areas those might be the first ones to include in the test-suite.
> Best

Yes, but the examples do not do any hard checks in general (maybe
implicitly if you look at the output produced and notice unplausible
values). So from my point of view they do not qualify really as tests
?

>
>
> ----- Original Message -----
>>
>>
>> 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 >
>> ------------------------------------------------------------------------------
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog
>> now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>

Re: [Quantlib-dev] test-suite coverage

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

Peter, I already knew marketing isn't my thing. Did you notice how much
space I give in my book to the shortcomings of the library? :)

Wait. Did I just market my book? My mind is blown!


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>

Re: [Quantlib-dev] test-suite coverage

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

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>

Re: [Quantlib-dev] test-suite coverage

[<ja...@fr...>]

Hello, 
I know it does not serve the same purpose but there might be some information in running the same experiment with the examples or the various add-ins/wrappers. If there is still some dark areas those might be the first ones to include in the test-suite. 
Best


----- Original Message -----
> 
> 
> 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 >
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog
> now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

Re: [Quantlib-dev] test-suite coverage

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

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>

Re: [Quantlib-dev] test-suite coverage

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

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>