quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Git migration complete

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

Hi all,
    the new Git repository is now live at
<https://github.com/lballabio/quantlib>. The site was updated to
reflect the change.

For the developers that had write access: please register to GitHub
and fork it. For the time being, I'll pull from your repos while we
figure out a workflow.  This also goes to whoever wants to contribute
patches (I'll keep accepting patches the usual way, of course, but
using pull requests will make it easier for me to merge them).

Happy forking,
    Luigi

Re: [Quantlib-dev] Svn/git migration

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

Hi Dirk,
    I still have to investigate how to set permissions, but at the
very least I'll pull any changes you push to your own clone.

Luigi


On Tue, Jun 4, 2013 at 3:54 PM, Dirk Eddelbuettel <ed...@de...> wrote:
>
> On 4 June 2013 at 14:47, Luigi Ballabio wrote:
> | Yes.  The details are in a post I sent to the mailing lists during the weekend.
>
> One wish from someone stuck in his SVN ways: can you allow direct pushing for
> those who had svn write?  My changes are usually fairly minimal, and I have
> hence not yet adapted to the full branching mental mode of git -- but have
> merrily pushed changes to a few git(hub) repos that permitted direct writes.
>
> Dirk
>
> --
> Dirk Eddelbuettel | ed...@de... | http://dirk.eddelbuettel.com

Re: [Quantlib-dev] Svn/git migration

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

Hi Pepe,
    I'll put the full repository on github (that is, including the C++
library, the SWIG extensions and the QLXL modules).

Luigi


On Tue, Jun 4, 2013 at 5:53 PM,  <ja...@fr...> wrote:
> Hi all, Eric
> Would it be possible to have a forkebable copy of QLXL at github too? I mean, please.
> Regards
> pp
>
>
> ----- Original Message -----
> From: "Dirk Eddelbuettel" <ed...@de...>
> To: "Luigi Ballabio" <lui...@gm...>
> Cc: qua...@li..., "QuantLib users" <qua...@li...>
> Sent: Tuesday, 4 June, 2013 3:54:06 PM
> Subject: Re: [Quantlib-dev] Svn/git migration
>
>
> On 4 June 2013 at 14:47, Luigi Ballabio wrote:
> | Yes.  The details are in a post I sent to the mailing lists during the weekend.
>
> One wish from someone stuck in his SVN ways: can you allow direct pushing for
> those who had svn write?  My changes are usually fairly minimal, and I have
> hence not yet adapted to the full branching mental mode of git -- but have
> merrily pushed changes to a few git(hub) repos that permitted direct writes.
>
> Dirk
>
> --
> Dirk Eddelbuettel | ed...@de... | http://dirk.eddelbuettel.com
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Svn/git migration

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

Hi all, Eric
Would it be possible to have a forkebable copy of QLXL at github too? I mean, please.
Regards
pp


----- Original Message -----
From: "Dirk Eddelbuettel" <ed...@de...>
To: "Luigi Ballabio" <lui...@gm...>
Cc: qua...@li..., "QuantLib users" <qua...@li...>
Sent: Tuesday, 4 June, 2013 3:54:06 PM
Subject: Re: [Quantlib-dev] Svn/git migration


On 4 June 2013 at 14:47, Luigi Ballabio wrote:
| Yes.  The details are in a post I sent to the mailing lists during the weekend.

One wish from someone stuck in his SVN ways: can you allow direct pushing for
those who had svn write?  My changes are usually fairly minimal, and I have
hence not yet adapted to the full branching mental mode of git -- but have
merrily pushed changes to a few git(hub) repos that permitted direct writes.

Dirk

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

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Svn/git migration

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

On 4 June 2013 at 14:47, Luigi Ballabio wrote:
| Yes.  The details are in a post I sent to the mailing lists during the weekend.

One wish from someone stuck in his SVN ways: can you allow direct pushing for
those who had svn write?  My changes are usually fairly minimal, and I have
hence not yet adapted to the full branching mental mode of git -- but have
merrily pushed changes to a few git(hub) repos that permitted direct writes.

Dirk

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

Re: [Quantlib-dev] QuantLib R package from SWIG code

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

Hi Luigi,

On 4 June 2013 at 12:19, Luigi Ballabio wrote:
| Hi Dirk,
|     yes, let's merge it after release. We'll autoconf it so that the
| cpp is generated in the correct place and the other files are created,
| too.

Sounds good. We'll tackle this off-line.
 
| Re the swap enumeration: it might be due to the shenanigans we're
| doing to hide the shared pointers from the interface. Option::Put,
| that you see, is exported directly (see options.i:40).
| VanillaSwap::Payer is first hidden, then re-exported as a static const
| data member (see swap.i, line 56 and onwards). Does SWIG/R manage
| this?

I will attest to complete ignorance as to what SWIG/R does. That was AFAIK
all Joseph Wang--and singlehandedly.

Dirk
 
| Luigi
| 
| 
| 
| On Tue, Jun 4, 2013 at 3:06 AM, Dirk Eddelbuettel <ed...@de...> wrote:
| >
| > Hi all,
| >
| > A few days ago I finally made an attempt at turning the few files usually
| > contained in the QL-SWIG directory for R (eg makeRData.R, QuantLib.cpp,
| > QuantLib.R) into a proper R package (in the sense of the ~ 4500 CRAN
| > packages).
| >
| > It is straightforward.  A working version is committed in the SVN of my
| > earlier (and more limited) explicit RQuantLib wrapping at R-Forge [1].  One
| > only needs this minimal layout:
| >
| >    edd@max:~/svn/rquantlib/pkg/QuantLib$ tree
| >    .
| >    ├── cleanup
| >    ├── demo                    # mostly files by Joseph Wang
| >    │   ├── 00Index             # index of demos
| >    │   ├── bates.R             # a file by Klaus Spanderen
| >    │   ├── bonds.R             # something I added, see below
| >    │   ├── europeanOption.R
| >    │   ├── fdOption.R
| >    │   ├── graph.R
| >    │   ├── scatter.R
| >    │   ├── swap.R              # incomplete, see below
| >    │   └── wireframe.R
| >    ├── DESCRIPTION
| >    ├── NAMESPACE
| >    ├── R
| >    │   ├── makeRData.R         # not needed
| >    │   └── QuantLib.R
| >    └── src
| >        ├── Makevars
| >        └── QuantLib.cpp
| >
| >    3 directories, 16 files
| >    edd@max:~/svn/rquantlib/pkg/QuantLib$
| >
| > where
| >     a) demo/ is an optional directory with examples or demos,
| >     b) makeRData.R is all commented-out (!!) and
| >     c) the files R/QuantLib.R and src/QuantLib.cpp are _unaltered_ copies
| >        from the current QL-SWIG files.
| > DESCRIPTION and NAMESPACE are needed per R standards for packages.  The rest
| > is gravy: src/Makevars is two lines calling quantlib-config. We can easily
| > autoconf this.
| >
| > The main advantage: it now behaves like a standard R packages, and users can
| > do   library(QuantLib)   as they would with any other package. [ It will
| > never pass QA tests for R as every exported function would need a manual page
| > etc pp. The code is also fragile, it is pretty easy to end up with segfaults. ]
| >
| > Now, I don't want to suggest that we shoehorn this into 1.3 if QL 1.3 is coming
| > soon, but maybe the one after would fit if anybody else is interested in R
| > integration?  I'd also be happy to keep it outside of QL if that is prefered.
| >
| > Also, I spent some time on the weekend translating bonds.py into bonds.R.
| > That worked nicely, see below [2] I also tried to translate swap.py -- but
| > just realized that the enum type for the Payer vs Receiver is not in the
| > QuantLib.R file [3].  Any idea?   I may translate some more of the existing
| > examples from Python or other directories.
| >
| > Feedback welcome.
| >
| > Dirk
| >
| >
| > [1] You can browse the SVN here:
| >     https://r-forge.r-project.org/scm/viewvc.php/pkg/QuantLib/?root=rquantlib
| >
| > [2] A quick transcript
| >
| > edd@max:~/svn/rquantlib/pkg/QuantLib$ R --slave -e 'source("demo/bonds.R")'
| > Today :[1] "2008-09-15"
| > Settlement Date: [1] "2008-09-18"
| >
| > Results:
| >                 zeroCoupon fixedRate floatingRate
| > NPV                100.922 107.66829  102.3593146
| > Clean Price        100.922 106.12753  101.7972017
| > Dirty Price        100.922 107.66829  102.3593146
| > Accrued Amount       0.000   1.54076    0.5621129
| > Previous Coupon         NA   0.04500    0.0288625
| > Next Coupon             NA   0.04500    0.0342984
| >
| > Sample indirect computations (for the floating rate bond):
| > Yield to Clean Price: [1] 101.797
| > Clean Price to Yield: [1] 0.0220096
| > edd@max:~/svn/rquantlib/pkg/QuantLib$
| >
| >
| > [3] No Payer/Receiver enum for Vanilla Swap, other enums are defined:
| >
| > edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Payer R/QuantLib.R
| > edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Put R/QuantLib.R
| >                         'Put' = -1,
| > edd@max:~/svn/rquantlib/pkg/QuantLib$
| >
| > --
| > Dirk Eddelbuettel | ed...@de... | http://dirk.eddelbuettel.com
| >
| > ------------------------------------------------------------------------------
| > How ServiceNow helps IT people transform IT departments:
| > 1. A cloud service to automate IT design, transition and operations
| > 2. Dashboards that offer high-level views of enterprise services
| > 3. A single system of record for all IT processes
| > http://p.sf.net/sfu/servicenow-d2d-j
| > _______________________________________________
| > QuantLib-dev mailing list
| > Qua...@li...
| > https://lists.sourceforge.net/lists/listinfo/quantlib-dev

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

Re: [Quantlib-dev] Svn/git migration

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

Yes.  The details are in a post I sent to the mailing lists during the weekend.

Luigi

On Tue, Jun 4, 2013 at 2:43 PM, Grześ Andruszkiewicz <gan...@gm...> wrote:
> Hi Luigi,
>
> Does it mean that the git repository will become the primary one?
>
> Grzegorz
>
>
> On 4 June 2013 13:37, Luigi Ballabio <lui...@gm...> wrote:
>>
>> Hi all,
>>     if no one tries to stop me, I'll start migrating the repository
>> tomorrow.  The subversion repository will remain accessible in the
>> meantime, but it will be read-only.  I'll let you know when it's over
>> (hopefully, late tomorrow or the morning after).
>>
>> Later,
>>     Luigi
>>
>>
>> ------------------------------------------------------------------------------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Re: [Quantlib-dev] Svn/git migration

[Grześ A. <gan...@gm...>]

Hi Luigi,

Does it mean that the git repository will become the primary one?

Grzegorz


On 4 June 2013 13:37, Luigi Ballabio <lui...@gm...> wrote:

> Hi all,
>     if no one tries to stop me, I'll start migrating the repository
> tomorrow.  The subversion repository will remain accessible in the
> meantime, but it will be read-only.  I'll let you know when it's over
> (hopefully, late tomorrow or the morning after).
>
> Later,
>     Luigi
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Svn/git migration

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

Hi all,
    if no one tries to stop me, I'll start migrating the repository
tomorrow.  The subversion repository will remain accessible in the
meantime, but it will be read-only.  I'll let you know when it's over
(hopefully, late tomorrow or the morning after).

Later,
    Luigi

Re: [Quantlib-dev] QuantLib R package from SWIG code

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

Hi Dirk,
    yes, let's merge it after release. We'll autoconf it so that the
cpp is generated in the correct place and the other files are created,
too.

Re the swap enumeration: it might be due to the shenanigans we're
doing to hide the shared pointers from the interface. Option::Put,
that you see, is exported directly (see options.i:40).
VanillaSwap::Payer is first hidden, then re-exported as a static const
data member (see swap.i, line 56 and onwards). Does SWIG/R manage
this?

Luigi



On Tue, Jun 4, 2013 at 3:06 AM, Dirk Eddelbuettel <ed...@de...> wrote:
>
> Hi all,
>
> A few days ago I finally made an attempt at turning the few files usually
> contained in the QL-SWIG directory for R (eg makeRData.R, QuantLib.cpp,
> QuantLib.R) into a proper R package (in the sense of the ~ 4500 CRAN
> packages).
>
> It is straightforward.  A working version is committed in the SVN of my
> earlier (and more limited) explicit RQuantLib wrapping at R-Forge [1].  One
> only needs this minimal layout:
>
>    edd@max:~/svn/rquantlib/pkg/QuantLib$ tree
>    .
>    ├── cleanup
>    ├── demo                    # mostly files by Joseph Wang
>    │   ├── 00Index             # index of demos
>    │   ├── bates.R             # a file by Klaus Spanderen
>    │   ├── bonds.R             # something I added, see below
>    │   ├── europeanOption.R
>    │   ├── fdOption.R
>    │   ├── graph.R
>    │   ├── scatter.R
>    │   ├── swap.R              # incomplete, see below
>    │   └── wireframe.R
>    ├── DESCRIPTION
>    ├── NAMESPACE
>    ├── R
>    │   ├── makeRData.R         # not needed
>    │   └── QuantLib.R
>    └── src
>        ├── Makevars
>        └── QuantLib.cpp
>
>    3 directories, 16 files
>    edd@max:~/svn/rquantlib/pkg/QuantLib$
>
> where
>     a) demo/ is an optional directory with examples or demos,
>     b) makeRData.R is all commented-out (!!) and
>     c) the files R/QuantLib.R and src/QuantLib.cpp are _unaltered_ copies
>        from the current QL-SWIG files.
> DESCRIPTION and NAMESPACE are needed per R standards for packages.  The rest
> is gravy: src/Makevars is two lines calling quantlib-config. We can easily
> autoconf this.
>
> The main advantage: it now behaves like a standard R packages, and users can
> do   library(QuantLib)   as they would with any other package. [ It will
> never pass QA tests for R as every exported function would need a manual page
> etc pp. The code is also fragile, it is pretty easy to end up with segfaults. ]
>
> Now, I don't want to suggest that we shoehorn this into 1.3 if QL 1.3 is coming
> soon, but maybe the one after would fit if anybody else is interested in R
> integration?  I'd also be happy to keep it outside of QL if that is prefered.
>
> Also, I spent some time on the weekend translating bonds.py into bonds.R.
> That worked nicely, see below [2] I also tried to translate swap.py -- but
> just realized that the enum type for the Payer vs Receiver is not in the
> QuantLib.R file [3].  Any idea?   I may translate some more of the existing
> examples from Python or other directories.
>
> Feedback welcome.
>
> Dirk
>
>
> [1] You can browse the SVN here:
>     https://r-forge.r-project.org/scm/viewvc.php/pkg/QuantLib/?root=rquantlib
>
> [2] A quick transcript
>
> edd@max:~/svn/rquantlib/pkg/QuantLib$ R --slave -e 'source("demo/bonds.R")'
> Today :[1] "2008-09-15"
> Settlement Date: [1] "2008-09-18"
>
> Results:
>                 zeroCoupon fixedRate floatingRate
> NPV                100.922 107.66829  102.3593146
> Clean Price        100.922 106.12753  101.7972017
> Dirty Price        100.922 107.66829  102.3593146
> Accrued Amount       0.000   1.54076    0.5621129
> Previous Coupon         NA   0.04500    0.0288625
> Next Coupon             NA   0.04500    0.0342984
>
> Sample indirect computations (for the floating rate bond):
> Yield to Clean Price: [1] 101.797
> Clean Price to Yield: [1] 0.0220096
> edd@max:~/svn/rquantlib/pkg/QuantLib$
>
>
> [3] No Payer/Receiver enum for Vanilla Swap, other enums are defined:
>
> edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Payer R/QuantLib.R
> edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Put R/QuantLib.R
>                         'Put' = -1,
> edd@max:~/svn/rquantlib/pkg/QuantLib$
>
> --
> Dirk Eddelbuettel | ed...@de... | http://dirk.eddelbuettel.com
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Compiling quantlib on Solaris X86 using Workshop

[Mike S. <ma...@gm...>]

Hi all,

The PrimitivePolynomial array is declared as "extern" only when the code is
compiled as C++, which seems like it would cause problems in files compiled
as straight C.

I think this was fixed a couple months ago making sure that Visual Studio
2012 compiles better with level 4 warnings enabled so it should be part of
the next release. The change I made was to move the extern keyword out of
the #ifdef __cplusplus block before the variable declaration to the line
directly above the #ifdef.

Unfortunately, I don't have access to the problem configuration so I can't
be sure, but it should be simple to check to see if that solves the problem.

Mike


On Mon, Jun 3, 2013 at 7:50 AM, Luigi Ballabio <lui...@gm...>wrote:

> Hello Paul,
>     thanks for the report.  As for (a), would <cmath> and <cstdlib>
> work as well instead of math.h and stdlib.h? May you try it if you
> didn't already?
>
> (b) is strange. It looks like your compiler requires
> primitivepolynomials.c to be compiled as C++ instead of plain C, but I
> have no idea why...
>
> Luigi
>
>
> On Fri, May 24, 2013 at 3:18 PM,  <Pau...@de...> wrote:
> >
> > Hello!
> >
> > We compiled quantlib on a SunOS 5.10, using Sun Workshop 12.2 (cc: Sun C
> > 5.11 SunOS_i386 2010/08/13) for 64bit.
> > We used the latest boost  (1.53.0).
> > Our configure was not special:
> > ./configure --with-boost-include=../boost_1_53_0
> > --with-boost-lib=../boost_1_53_0/libs
> >
> > However we used:
> > CXXFLAGS=-library=stlport4 -m64
> >
> > We managed to compile the lib, but had to do some changes:
> > a) includes
> > We had to include "math.h and stdlib.h" to cpicoupon.cpp
> >
> > We had to include math.h to:
> > riskyassetswapoption.cpp
> > blackdeltacalculator.cpp
> > cpicapfloorengines.cpp
> > zigguratrng.cpp
> > analyticvariancegammaengine.cpp
> > fftvanillaengine.cpp
> > fftvariancegammaengine.cpp
> > cpiswap.cpp
> > cpibond.cpp
> > analyticgjrgarchengine.cpp
> > seasonality.hpp
> >
> > b) Unresolved external
> > We had a problem with the linker for
> > const long *const PrimitivePolynomials[N_MAX_DEGREE];
> >
> >  coming from "primitivepolynonimals.h" / "primitivepolynominals.c"
> >
> > Somehow the linker didn't linke the function to the sobolrsg.cpp
> > Couldn't find out why, but the nm-command showed the symbol twice: once
> > defined and once undefined.
> >
> > After changing the file to .hpp and .cpp all worked fine.
> >
> > We addidionaly compiled the Swig for java, because we'll call from java
> to
> > calc theo option prices.
> > For java we additionaly had to include -Kpic for the linker.
> >
> > I wanted to let you know of the these problems.
> > Maybe there is a better way or maybe the ql can be adepted? I think the
> > changes don't harm for other compilers?
> >
> > (By the way: we didn't have any problems on Windows)
> >
> > And thanx for the great work. We're using the lib only in a sample up to
> > now, but that might change in the future...
> >
> > Best regards,
> > Paul Rädle
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Deutsche Börse AG
> > Chairman of the Supervisory Board/
> > Vorsitzender des Aufsichtsrats:
> > Dr. Joachim Faber
> > Executive Board/Vorstand:
> > Dr. Reto Francioni (Chief Executive Officer/Vorsitzender),
> > Andreas Preuss (Deputy Chief Executive Officer/
> > stellv. Vorsitzender), Gregor Pottmeyer,
> > Hauke Stars, Jeffrey Tessler.
> > Aktiengesellschaft with registered seat in/mit Sitz in
> > Frankfurt am Main.
> > Commercial register/Handelsregister: HRB 32232
> > Local court/Amtsgericht Frankfurt am Main.
> >
> > -----------------------------------------
> > Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte
> Informationen.
> > Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
> > sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
> > dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
> > ist nicht gestattet.
> >
> > The information contained in this message is confidential or protected by
> > law. If you are not the intended recipient, please contact the sender and
> > delete this message. Any unauthorised copying of this message or
> > unauthorised distribution of the information contained herein is
> prohibited.
> >
> > Legally required information for business correspondence/
> > Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
> > http://deutsche-boerse.com/letterhead
> >
> >
> >
> ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_may
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] QuantLib R package from SWIG code

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

On 3 June 2013 at 20:06, Dirk Eddelbuettel wrote:
| edd@max:~/svn/rquantlib/pkg/QuantLib$ R --slave -e 'source("demo/bonds.R")'
| Today :[1] "2008-09-15"
| Settlement Date: [1] "2008-09-18"
| 
| Results:
|                 zeroCoupon fixedRate floatingRate
| NPV                100.922 107.66829  102.3593146
| Clean Price        100.922 106.12753  101.7972017
| Dirty Price        100.922 107.66829  102.3593146
| Accrued Amount       0.000   1.54076    0.5621129
| Previous Coupon         NA   0.04500    0.0288625
| Next Coupon             NA   0.04500    0.0342984
| 
| Sample indirect computations (for the floating rate bond):
| Yield to Clean Price: [1] 101.797
| Clean Price to Yield: [1] 0.0220096
| edd@max:~/svn/rquantlib/pkg/QuantLib$ 

Here is the same from slightly better version (and now source'd from R)

R> source("bonds.R")
Today :[1] "2008-09-15"
Settlement Date: [1] "2008-09-18"

Results:
                zeroCoupon fixedRate floatingRate
NPV               100.9222  107.6683    102.35931
Clean Price       100.9222  106.1275    101.79720
Dirty Price       100.9222  107.6683    102.35931
Accrued Amount      0.0000    1.5408      0.56211
Previous Coupon         NA    4.5000      2.88625
Next Coupon             NA    4.5000      3.42984
Yield               3.0001    3.6476      2.20096

Sample indirect computations (for the floating rate bond):
Yield to Clean Price: [1] 101.797
Clean Price to Yield: [1] 0.0220096


The file is in the SVN repo for R. It starts with library(QuantLib), the
three lines in Joe's README can also be used to load the shared library and
pre-created data types.  I'd be happy to check it into QuantLib too.

Dirk


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

[Quantlib-dev] QuantLib R package from SWIG code

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

Hi all,

A few days ago I finally made an attempt at turning the few files usually
contained in the QL-SWIG directory for R (eg makeRData.R, QuantLib.cpp,
QuantLib.R) into a proper R package (in the sense of the ~ 4500 CRAN
packages).

It is straightforward.  A working version is committed in the SVN of my
earlier (and more limited) explicit RQuantLib wrapping at R-Forge [1].  One
only needs this minimal layout:

   edd@max:~/svn/rquantlib/pkg/QuantLib$ tree
   .
   ├── cleanup
   ├── demo                    # mostly files by Joseph Wang
   │   ├── 00Index             # index of demos
   │   ├── bates.R             # a file by Klaus Spanderen
   │   ├── bonds.R             # something I added, see below
   │   ├── europeanOption.R    
   │   ├── fdOption.R
   │   ├── graph.R
   │   ├── scatter.R
   │   ├── swap.R              # incomplete, see below
   │   └── wireframe.R
   ├── DESCRIPTION
   ├── NAMESPACE
   ├── R
   │   ├── makeRData.R         # not needed
   │   └── QuantLib.R
   └── src
       ├── Makevars
       └── QuantLib.cpp

   3 directories, 16 files
   edd@max:~/svn/rquantlib/pkg/QuantLib$ 

where 
    a) demo/ is an optional directory with examples or demos, 
    b) makeRData.R is all commented-out (!!) and 
    c) the files R/QuantLib.R and src/QuantLib.cpp are _unaltered_ copies
       from the current QL-SWIG files.
DESCRIPTION and NAMESPACE are needed per R standards for packages.  The rest
is gravy: src/Makevars is two lines calling quantlib-config. We can easily
autoconf this.

The main advantage: it now behaves like a standard R packages, and users can
do   library(QuantLib)   as they would with any other package. [ It will
never pass QA tests for R as every exported function would need a manual page
etc pp. The code is also fragile, it is pretty easy to end up with segfaults. ]

Now, I don't want to suggest that we shoehorn this into 1.3 if QL 1.3 is coming
soon, but maybe the one after would fit if anybody else is interested in R
integration?  I'd also be happy to keep it outside of QL if that is prefered.

Also, I spent some time on the weekend translating bonds.py into bonds.R.
That worked nicely, see below [2] I also tried to translate swap.py -- but
just realized that the enum type for the Payer vs Receiver is not in the
QuantLib.R file [3].  Any idea?   I may translate some more of the existing
examples from Python or other directories.

Feedback welcome.

Dirk


[1] You can browse the SVN here:
    https://r-forge.r-project.org/scm/viewvc.php/pkg/QuantLib/?root=rquantlib

[2] A quick transcript

edd@max:~/svn/rquantlib/pkg/QuantLib$ R --slave -e 'source("demo/bonds.R")'
Today :[1] "2008-09-15"
Settlement Date: [1] "2008-09-18"

Results:
                zeroCoupon fixedRate floatingRate
NPV                100.922 107.66829  102.3593146
Clean Price        100.922 106.12753  101.7972017
Dirty Price        100.922 107.66829  102.3593146
Accrued Amount       0.000   1.54076    0.5621129
Previous Coupon         NA   0.04500    0.0288625
Next Coupon             NA   0.04500    0.0342984

Sample indirect computations (for the floating rate bond):
Yield to Clean Price: [1] 101.797
Clean Price to Yield: [1] 0.0220096
edd@max:~/svn/rquantlib/pkg/QuantLib$ 


[3] No Payer/Receiver enum for Vanilla Swap, other enums are defined:

edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Payer R/QuantLib.R 
edd@max:~/svn/rquantlib/pkg/QuantLib$ grep Put R/QuantLib.R 
                        'Put' = -1, 
edd@max:~/svn/rquantlib/pkg/QuantLib$ 

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

Re: [Quantlib-dev] Compiling quantlib on Solaris X86 using Workshop

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

Hello Paul,
    thanks for the report.  As for (a), would <cmath> and <cstdlib>
work as well instead of math.h and stdlib.h? May you try it if you
didn't already?

(b) is strange. It looks like your compiler requires
primitivepolynomials.c to be compiled as C++ instead of plain C, but I
have no idea why...

Luigi


On Fri, May 24, 2013 at 3:18 PM,  <Pau...@de...> wrote:
>
> Hello!
>
> We compiled quantlib on a SunOS 5.10, using Sun Workshop 12.2 (cc: Sun C
> 5.11 SunOS_i386 2010/08/13) for 64bit.
> We used the latest boost  (1.53.0).
> Our configure was not special:
> ./configure --with-boost-include=../boost_1_53_0
> --with-boost-lib=../boost_1_53_0/libs
>
> However we used:
> CXXFLAGS=-library=stlport4 -m64
>
> We managed to compile the lib, but had to do some changes:
> a) includes
> We had to include "math.h and stdlib.h" to cpicoupon.cpp
>
> We had to include math.h to:
> riskyassetswapoption.cpp
> blackdeltacalculator.cpp
> cpicapfloorengines.cpp
> zigguratrng.cpp
> analyticvariancegammaengine.cpp
> fftvanillaengine.cpp
> fftvariancegammaengine.cpp
> cpiswap.cpp
> cpibond.cpp
> analyticgjrgarchengine.cpp
> seasonality.hpp
>
> b) Unresolved external
> We had a problem with the linker for
> const long *const PrimitivePolynomials[N_MAX_DEGREE];
>
>  coming from "primitivepolynonimals.h" / "primitivepolynominals.c"
>
> Somehow the linker didn't linke the function to the sobolrsg.cpp
> Couldn't find out why, but the nm-command showed the symbol twice: once
> defined and once undefined.
>
> After changing the file to .hpp and .cpp all worked fine.
>
> We addidionaly compiled the Swig for java, because we'll call from java to
> calc theo option prices.
> For java we additionaly had to include -Kpic for the linker.
>
> I wanted to let you know of the these problems.
> Maybe there is a better way or maybe the ql can be adepted? I think the
> changes don't harm for other compilers?
>
> (By the way: we didn't have any problems on Windows)
>
> And thanx for the great work. We're using the lib only in a sample up to
> now, but that might change in the future...
>
> Best regards,
> Paul Rädle
>
>
>
>
> -------------------------------------------------------------------------
> Deutsche Börse AG
> Chairman of the Supervisory Board/
> Vorsitzender des Aufsichtsrats:
> Dr. Joachim Faber
> Executive Board/Vorstand:
> Dr. Reto Francioni (Chief Executive Officer/Vorsitzender),
> Andreas Preuss (Deputy Chief Executive Officer/
> stellv. Vorsitzender), Gregor Pottmeyer,
> Hauke Stars, Jeffrey Tessler.
> Aktiengesellschaft with registered seat in/mit Sitz in
> Frankfurt am Main.
> Commercial register/Handelsregister: HRB 32232
> Local court/Amtsgericht Frankfurt am Main.
>
> -----------------------------------------
> Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.
> Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
> sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
> dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
> ist nicht gestattet.
>
> The information contained in this message is confidential or protected by
> law. If you are not the intended recipient, please contact the sender and
> delete this message. Any unauthorised copying of this message or
> unauthorised distribution of the information contained herein is prohibited.
>
> Legally required information for business correspondence/
> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
> http://deutsche-boerse.com/letterhead
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Project news

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

Hi all,
    a couple of project news.  The first is that a 1.3 release is long
overdue.  Well, that's not news at all, of course; the news is that I
want to get it out some time this month.  It's going to include quite
a few contributions, but not all we have received.  The blame is
squarely on me for not finding enough time to merge all of them;
however, I'd rather release what is there now, rather than waiting to
include more (and probably leaving out more contributions that would
come in the meantime).  If you sent a patch and don't see it in this
release, apologies; they'll be in the next (I'll try to shorten the
release cycle).
In particular, there's a couple of contributions from Mortoray and
Riccardo Ghetta that I've left out in the rain. They're two different
ways to make it easier to work around the singletons such as Settings.
 They're both valid, and I'm not quite sure what to do, so I'll try
and make them both available for review after the release---which
brings me to the second piece of news.

In the past few months, I've maintained a mirror of the QuantLib
repository on github, and a few people used it to contribute. Overall,
I've been quite happy of the experience as it made a lot easier to
share patches, review and apply them. I've brought it up with Nando
and Eric (the idea had been floating around for a while) and we agreed
to move the code there. The migration can be done in just a day or two
(in fact, I've tried the conversion once already and it went
smoothly).  It will open a series of possibilities; for instance, when
someone clones the repository and adds a patch, not only I'll be able
to merge it more easily into the "official" repository, but anybody
needing the patch will also be able to check out the modified version
from the clone without having to wait for me to get my acts together.
Another possibility will be to push modified versions of the code on
github in alternate branches, so that it's easier to review and
comment them (for instance, this is what I would do with Mortoray's
and Riccardo's patches).  And of course, it will make it much easier
for anybody to maintain a set of proprietary modifications while at
the same time keeping track of changes in the official library.
Anyway: I'll give you all a shout a few days before the migration. I'd
like to do it shortly, before creating the 1.3 release branch.

There would be more to discuss (whether we should start thinking of a
2.0, for instance, and how to change it in order to make it possible
to use it for parallel calculations; or when to start allowing C++11
features; or whether we really need both the quantlib-users and
quantlib-dev mailing lists) but it can wait for future posts. For now,
that's enough blabbering from me. As usual, I'm here for any feedback.

Later,
    Luigi

Re: [Quantlib-dev] c++0x

[Mike S. <ma...@gm...>]

In regards to keeping the auto_ptr constructor available, I think the
"#define unique_ptr auto_ptr" macro confused me a little bit. I've had a
chance to look into the code today after your feedback, and things are a
lot clearer now.

I've looked into replacing that with a templated typedef, as described by
Herb Sutter at http://www.gotw.ca/gotw/079.htm. Ironically, this would not
be necessary with other new C++11 features, but if it were possible to rely
on those being present we could just use unique_ptr all the time. There
shouldn't be a need to keep the Clone(std::auto_ptr<T>); constructor around
and the templated typedef makes the implementation cleaner while also
preventing quantlib from redefining unique_ptr in client code.

To answer the second question about forcing client code to call std::move()
to transfer ownership of the pointer, that is exactly correct.
Moving from ptrA to ptrB means that any accesses of ptrA besides
reassignment and destruction are undefined behavior.  std::move() appearing
in client code acts as a sort of flag or barrier warning programmers of
this circumstance, so it's unexpected to hide that in a function that takes
a reference. For more information, a good starting point would be this
stack overflow question: http://stackoverflow.com/q/3451099/1181561.

I've committed the two changes I've described to a branch on github if
you'd like to take a look:
https://github.com/masrtis/quantlib/commit/e3b0f3a3ee2c245f3feb60d998687ebcf6e32bd2

Mike


On Fri, May 31, 2013 at 2:06 PM, Peter Caspers <pca...@gm...>wrote:

> Hi Mike,
>
> thank you for your comments. My original goal was to completely get rid
> of auto_ptr (since depricated), therefore I removed the constructor
> taking an auto_ptr. From what you write below I understand that we
> should keep it, but I do not quite get why. Could you explain this point
> again please?
>
> I do get your two points about the Clone(std::unique_ptr<T>&)
> constructor though. If I write
>
> Clone(std::unique_ptr<T> p);
>
> and passing a std::unique_ptr<T> to it the compiler complains that I am
> using a deleted function which I understand is because unique_ptr can
> not be copied, i.e. example 1 would be illegal. Therefore one would then
> have to change the client code passing std::move(p) instead of p
> directly, as in example 2. E.g. line 3202 in test-suite/marketmodel.cpp
> would
> then change as follows
>
>                          PathwiseVegasAccountingEngine
> accountingengine(boost::shared_ptr<LogNormalFwdRateEuler>(new
> LogNormalFwdRateEuler(evolver)), // method relies heavily on LMM Euler
> -                            productToUse,
> +                            std::move(productToUse),
>                              marketModel, // we need pseudo-roots and
> displacements
>                              vegaBumps,
>                              initialNumeraireValue);
>
> Example 3 would also work.
>
> Is that what you propose ?
>
> regards
>  Peter
>
> Mike Sharpe <ma...@gm...> writes:
>
> > Hi Peter,
> >
> > First off, thanks for taking a look at getting C++11 into a major
> project!
> >
> > The line
> >     Clone(std::unique_ptr<T>& p);
> >
> > looks suspicious to me. It doesn't make it clear from the client side
> that the
> > pointer ownership was changed. Compare the following three examples:
> >     // example 1
> >     std::unique_ptr<T> ptr(new T());
> >     Clone<T> newObject(ptr);
> >     // example 2
> >     std::unique_ptr<T> ptr(new T());
> >     Clone<T> newObject(std::move(ptr));
> >     //example 3
> >     Clone<T> newObject(std::unique_ptr<T>(new T()); // 3
> >
> > Example 2 makes it obvious that the constructor will retain ownership of
> the
> > unique_ptr, which isn't obvious in example 1 even though the current
> > implementation means example 1 and example 2 are the same. In addition,
> the
> > current code will remove the ability for clients to use code like
> example 3
> > completely, as you can't bind a temporary object to a non-const lvalue
> > reference. It's possible clients could run into problems even if they
> don't
> > upgrade from auto_ptr to unique_ptr if they have code like this.
> >
> > I propose that, instead of changing the function definition to
> incorporate
> > either auto_ptr or unique_ptr, that another Clone constructor is added,
> so that
> > there will be two constructors:
> >
> >   Clone(std::auto_ptr<T> ptr);
> > #ifdef QL_UNIQUE_PTR_ENABLED
> >   Clone(std::unique_ptr<T> ptr);
> > #endif
> >
> > The implementation of the auto_ptr constructor will need to make sure to
> > initialize the unique_ptr calling uniquePtr(std::move(autoPtr)) in the
> > initializer class if the internal class uses unique_ptr. This is
> > because unique_ptr has a constructor that accepts auto_ptr by rvalue
> reference
> > only, and rvalue references cannot bind to lvalues. But, you can base the
> > private data stored in clone off object internals simply off the
> > QL_UNIQUE_PTR_ENABLED #define, without clients having to change their
> code.
> > The decision to remove the auto_ptr constructor can be made later.
> >
> > Hopefully this helps. Let me know if an updated Clone.hpp would make
> things a
> > little bit clearer and I can put something together when I have some
> time.
> >
> > Mike
> >
> >
> > On Thu, May 30, 2013 at 9:13 AM, Peter Caspers <pca...@gm...>
> wrote:
> >
> >     following up the topic below: I missed to look at the test-suite,
> where
> >     some more
> >     auto_ptr would have to be replaced by unique_ptr.
> >
> >     https://github.com/pcaspers/quantlib/commit/
> >     466fbfbc423312eb7c4536ab59d861689cde70a0
> >
> >     Furthermore the header ql/utilities/clone.hpp has to be changed.
> >
> >     https://github.com/pcaspers/quantlib/commit/
> >     fe5a87dcfb60c10f1d8600b1511037e200915e4c
> >     https://github.com/pcaspers/quantlib/commit/
> >     7a12fc4c62b44d175dc794b487db0582803ef6a5
> >
> >     The test-suite now compiles and runs using g++ (with and without
> -std=
> >     c++0x)
> >     which is the main thing I guess. The whole thing does not look very
> >     nice though. Also I am not c++ expert enough to say that the upgrade
> of
> >     clone.hpp to unique_ptr should be done like this. Luigi ?
> >
> >     Thank you
> >      Peter
> >
> >     Peter Caspers <pca...@gm...> writes:
> >
> >     > Hi Luigi, all,
> >     >
> >     > we discussed compiling the core lib under the c++11 standard (e.g.
> with
> >     > g++ -std=c++0x). This produces some errors which can be fixed
> easily
> >     > (keeping backward compatibility):
> >     >
> >     > https://github.com/pcaspers/quantlib/commit/
> >     5b32b7705530264551e0622d0a2673813067be5b
> >     >
> >     > What is left is a bunch of warnings saying that std::auto_ptr is
> >     > depricated under c++11, the replacement being std::unique_ptr. A
> >     > possible solution is to replace the auto_ptr in the source by
> unique_ptr
> >     > (thus upgrading the code to c++11 already) and replace the
> unique_ptr by
> >     > auto_ptr again in case that compilation is done under c++ versions
> <
> >     > 11. I have done this here
> >     >
> >     > https://github.com/pcaspers/quantlib/commit/
> >     3e47a82a936112f12e3bb502292833d860f5aac9
> >     >
> >     > with a #define in qldefines.hpp resetting the pointers to auto_ptr
> again
> >     > based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
> >     > macro is available only in later boost versions so if one uses an
> older
> >     > one and provides no c++11 support he or she will get errors.
> Therefore
> >     > the following solution might be better
> >     >
> >     > https://github.com/pcaspers/quantlib/commit/
> >     6db965375b02094a7ea0da4e48efd7e0a1b8fd85
> >     >
> >     > using the __cplusplus macro to identify c++11. However since gcc
> sets
> >     > this macro simply to 1 in versions 4.6 (should be solved starting
> in
> >     > 4.7), I had to add another criterion for gcc based on
> >     > __GXX_EXPERIMENTAL_CXX0X_.
> >     >
> >     > For msvc 2010 the __cplusplus is also not 201103L but still
> 199711L. This
> >     > seems also to be the case in 2012 and this specific case was
> reported as
> >     a bug to
> >     > Microsoft,
> >     >
> >     > http://connect.microsoft.com/VisualStudio/feedback/details/763051/
> >     a-value-of-predefined-macro-cplusplus-is-still-199711l
> >     >
> >     > though not solved yet. Therefore I added a direct test on msvc
> 2010 or
> >     > higher versions based on _MSC_VER
> >     >
> >     > https://github.com/pcaspers/quantlib/commit/
> >     796beb89e2a707f951b77869bf869694e67ac769
> >     >
> >     > This final solution should work for all versions of msvc and gcc.
> I can
> >     not check other
> >     > compilers however.
> >     >
> >     > Since the #define seems a bit like a dirty hack we also thought of
> a
> >     > typedef. But then we would need a template typedef which is
> available
> >     only in
> >     > c++11 again and a metaprogramming-like workaround a la
> >     >
> >     > template<class T> struct PTR {
> >     >     typedef std::unique_ptr<T> Type;
> >     > };
> >     >
> >     > PTR<double>::Type a(new double(0.0));
> >     >
> >     > does not seem to improve the code either.
> >     >
> >     > Do you think we should do the upgrade to c++11 like propsed above
> or is
> >     there
> >     > maybe a better solution (I bet there is...). Or should we defer the
> >     > upgrade until a later release ? I personally would very much like
> to be
> >     > able to compile under c++11 without warnings already now.
> >     >
> >     > Thank you
> >     >  Peter
> >     >
> >     >
> >     >
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     Introducing AppDynamics Lite, a free troubleshooting tool for
> Java/.NET
> >     Get 100% visibility into your production application - at no cost.
> >     Code-level diagnostics for performance bottlenecks with <2% overhead
> >     Download for free and get started troubleshooting in minutes.
> >     http://p.sf.net/sfu/appdyn_d2d_ap1
> >     _______________________________________________
> >     QuantLib-dev mailing list
> >     Qua...@li...
> >     https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] c++0x

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

Hi Mike,

thank you for your comments. My original goal was to completely get rid
of auto_ptr (since depricated), therefore I removed the constructor
taking an auto_ptr. From what you write below I understand that we
should keep it, but I do not quite get why. Could you explain this point
again please?

I do get your two points about the Clone(std::unique_ptr<T>&)
constructor though. If I write

Clone(std::unique_ptr<T> p);

and passing a std::unique_ptr<T> to it the compiler complains that I am
using a deleted function which I understand is because unique_ptr can
not be copied, i.e. example 1 would be illegal. Therefore one would then
have to change the client code passing std::move(p) instead of p
directly, as in example 2. E.g. line 3202 in test-suite/marketmodel.cpp would
then change as follows

                         PathwiseVegasAccountingEngine accountingengine(boost::shared_ptr<LogNormalFwdRateEuler>(new LogNormalFwdRateEuler(evolver)), // method relies heavily on LMM Euler
-                            productToUse,
+                            std::move(productToUse),
                             marketModel, // we need pseudo-roots and displacements
                             vegaBumps,
                             initialNumeraireValue);

Example 3 would also work. 

Is that what you propose ?

regards
 Peter

Mike Sharpe <ma...@gm...> writes:

> Hi Peter,
>
> First off, thanks for taking a look at getting C++11 into a major project!
>  
> The line
>     Clone(std::unique_ptr<T>& p);
>
> looks suspicious to me. It doesn't make it clear from the client side that the
> pointer ownership was changed. Compare the following three examples:
>     // example 1
>     std::unique_ptr<T> ptr(new T());
>     Clone<T> newObject(ptr);
>     // example 2
>     std::unique_ptr<T> ptr(new T());
>     Clone<T> newObject(std::move(ptr));
>     //example 3
>     Clone<T> newObject(std::unique_ptr<T>(new T()); // 3
>
> Example 2 makes it obvious that the constructor will retain ownership of the
> unique_ptr, which isn't obvious in example 1 even though the current
> implementation means example 1 and example 2 are the same. In addition, the
> current code will remove the ability for clients to use code like example 3
> completely, as you can't bind a temporary object to a non-const lvalue
> reference. It's possible clients could run into problems even if they don't
> upgrade from auto_ptr to unique_ptr if they have code like this.
>  
> I propose that, instead of changing the function definition to incorporate
> either auto_ptr or unique_ptr, that another Clone constructor is added, so that
> there will be two constructors:
>
>   Clone(std::auto_ptr<T> ptr);
> #ifdef QL_UNIQUE_PTR_ENABLED
>   Clone(std::unique_ptr<T> ptr);
> #endif
>
> The implementation of the auto_ptr constructor will need to make sure to
> initialize the unique_ptr calling uniquePtr(std::move(autoPtr)) in the
> initializer class if the internal class uses unique_ptr. This is
> because unique_ptr has a constructor that accepts auto_ptr by rvalue reference
> only, and rvalue references cannot bind to lvalues. But, you can base the
> private data stored in clone off object internals simply off the
> QL_UNIQUE_PTR_ENABLED #define, without clients having to change their code.
> The decision to remove the auto_ptr constructor can be made later.
>  
> Hopefully this helps. Let me know if an updated Clone.hpp would make things a
> little bit clearer and I can put something together when I have some time.
>  
> Mike
>
>
> On Thu, May 30, 2013 at 9:13 AM, Peter Caspers <pca...@gm...> wrote:
>
>     following up the topic below: I missed to look at the test-suite, where
>     some more
>     auto_ptr would have to be replaced by unique_ptr.
>
>     https://github.com/pcaspers/quantlib/commit/
>     466fbfbc423312eb7c4536ab59d861689cde70a0
>
>     Furthermore the header ql/utilities/clone.hpp has to be changed.
>
>     https://github.com/pcaspers/quantlib/commit/
>     fe5a87dcfb60c10f1d8600b1511037e200915e4c
>     https://github.com/pcaspers/quantlib/commit/
>     7a12fc4c62b44d175dc794b487db0582803ef6a5
>
>     The test-suite now compiles and runs using g++ (with and without -std=
>     c++0x)
>     which is the main thing I guess. The whole thing does not look very
>     nice though. Also I am not c++ expert enough to say that the upgrade of
>     clone.hpp to unique_ptr should be done like this. Luigi ?
>
>     Thank you
>      Peter
>
>     Peter Caspers <pca...@gm...> writes:
>
>     > Hi Luigi, all,
>     >
>     > we discussed compiling the core lib under the c++11 standard (e.g. with
>     > g++ -std=c++0x). This produces some errors which can be fixed easily
>     > (keeping backward compatibility):
>     >
>     > https://github.com/pcaspers/quantlib/commit/
>     5b32b7705530264551e0622d0a2673813067be5b
>     >
>     > What is left is a bunch of warnings saying that std::auto_ptr is
>     > depricated under c++11, the replacement being std::unique_ptr. A
>     > possible solution is to replace the auto_ptr in the source by unique_ptr
>     > (thus upgrading the code to c++11 already) and replace the unique_ptr by
>     > auto_ptr again in case that compilation is done under c++ versions <
>     > 11. I have done this here
>     >
>     > https://github.com/pcaspers/quantlib/commit/
>     3e47a82a936112f12e3bb502292833d860f5aac9
>     >
>     > with a #define in qldefines.hpp resetting the pointers to auto_ptr again
>     > based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
>     > macro is available only in later boost versions so if one uses an older
>     > one and provides no c++11 support he or she will get errors. Therefore
>     > the following solution might be better
>     >
>     > https://github.com/pcaspers/quantlib/commit/
>     6db965375b02094a7ea0da4e48efd7e0a1b8fd85
>     >
>     > using the __cplusplus macro to identify c++11. However since gcc sets
>     > this macro simply to 1 in versions 4.6 (should be solved starting in
>     > 4.7), I had to add another criterion for gcc based on
>     > __GXX_EXPERIMENTAL_CXX0X_.
>     >
>     > For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
>     > seems also to be the case in 2012 and this specific case was reported as
>     a bug to
>     > Microsoft,
>     >
>     > http://connect.microsoft.com/VisualStudio/feedback/details/763051/
>     a-value-of-predefined-macro-cplusplus-is-still-199711l
>     >
>     > though not solved yet. Therefore I added a direct test on msvc 2010 or
>     > higher versions based on _MSC_VER
>     >
>     > https://github.com/pcaspers/quantlib/commit/
>     796beb89e2a707f951b77869bf869694e67ac769
>     >
>     > This final solution should work for all versions of msvc and gcc. I can
>     not check other
>     > compilers however.
>     >
>     > Since the #define seems a bit like a dirty hack we also thought of a
>     > typedef. But then we would need a template typedef which is available
>     only in
>     > c++11 again and a metaprogramming-like workaround a la
>     >
>     > template<class T> struct PTR {
>     >     typedef std::unique_ptr<T> Type;
>     > };
>     >
>     > PTR<double>::Type a(new double(0.0));
>     >
>     > does not seem to improve the code either.
>     >
>     > Do you think we should do the upgrade to c++11 like propsed above or is
>     there
>     > maybe a better solution (I bet there is...). Or should we defer the
>     > upgrade until a later release ? I personally would very much like to be
>     > able to compile under c++11 without warnings already now.
>     >
>     > Thank you
>     >  Peter
>     >
>     >
>     >
>     >
>
>     ------------------------------------------------------------------------------
>     Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>     Get 100% visibility into your production application - at no cost.
>     Code-level diagnostics for performance bottlenecks with <2% overhead
>     Download for free and get started troubleshooting in minutes.
>     http://p.sf.net/sfu/appdyn_d2d_ap1
>     _______________________________________________
>     QuantLib-dev mailing list
>     Qua...@li...
>     https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Yield curves

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

You can use interpolated curves. In Excel you can use qlDiscountCurve,
qlZeroCurve or qlForwardCurve; they interpolate discount factors, zero
yields or instantaneous forward rates, respectively.

Luigi

On Fri, May 31, 2013 at 1:17 PM, Grześ Andruszkiewicz
<gan...@gm...> wrote:
> Hi,
>
> I am currently using only flat curves for testing (e.g. qlFlatForward method
> in Excel plugin). How can I create other curve shapes? This is mainly for
> testing/demonstration purposes, I don't have any actual market data.
>
> Ciao,
> Grzegorz
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Evaluation Date

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

No, it's not possible.  It's something we'll have to think about in
the future, but as of now one can only modify the global evaluation
date.

Luigi

On Fri, May 31, 2013 at 1:15 PM, Grześ Andruszkiewicz
<gan...@gm...> wrote:
> Hi,
>
> Is it possible to set the valuation date for a single instrument? I am
> trying to check what would an instrument be worth in a years time in
> different scenarios, and compare it to today's value. It is all done in
> Excel, so changing the global evaluation date temporarily doesn't seem to be
> an option.
>
> Regards,
> Grzegorz
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Yield curves

[Grześ A. <gan...@gm...>]

Hi,

I am currently using only flat curves for testing (e.g. qlFlatForward
method in Excel plugin). How can I create other curve shapes? This is
mainly for testing/demonstration purposes, I don't have any actual market
data.

Ciao,
Grzegorz

[Quantlib-dev] Evaluation Date

[Grześ A. <gan...@gm...>]

Hi,

Is it possible to set the valuation date for a single instrument? I am
trying to check what would an instrument be worth in a years time in
different scenarios, and compare it to today's value. It is all done in
Excel, so changing the global evaluation date temporarily doesn't seem to
be an option.

Regards,
Grzegorz

Re: [Quantlib-dev] How to correctly Extend swig PiecewiseYieldCurve.i

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

There's a bunch of "using" directives in the file that extract the
class names from the QuantLib namespace. You'll probably have to add

using QuantLib::IterativeBootstrap;

to the existing ones.

Luigi


On Fri, May 31, 2013 at 12:41 AM, Irakli Machabeli
<ima...@ho...> wrote:
> I tried to add thrd parameter Bootstrap type to  export_piecewise_curve like
> this
>
> %define export_piecewise_curve(Name,Base,Interpolator,Bootstrap)
>
> and then
> export_piecewise_curve(PiecewiseFlatForward,ForwardRate,BackwardFlat,IterativeBootstrap);
>
> Code produced by swig looks like this
>
> SWIGINTERN PiecewiseFlatForwardPtr *new_PiecewiseFlatForwardPtr__SWIG_0(Date
> const &referenceDate,std::vector< boost::shared_ptr< RateHelper > > const
> &instruments,DayCounter const &dayCounter,std::vector< Handle< Quote > >
> const &jumps=std::vector< Handle< Quote > >(),std::vector< Date > const
> &jumpDates=std::vector< Date >(),Real accuracy=1.0e-12,BackwardFlat const
> &i=BackwardFlat()){
>             return new PiecewiseFlatForwardPtr(
>                 new
> PiecewiseYieldCurve<ForwardRate,BackwardFlat,IterativeBootstrap>(
>                                                  referenceDate,instruments,
>                                                  dayCounter, jumps,
> jumpDates,
>                                                  accuracy,i));
>         }
>
> And compiler curses
>
> Error    7    error C3206: 'boost::dynamic_pointer_cast' : invalid template
> argument for 'T', missing template argument list on class template
> 'QuantLib::PiecewiseYieldCurve'
> C:\quantliball\QuantLib-SWIG\CSharp\cpp\quantlib_wrap.cpp    7634    1
> NQuantLibc
>
> Error    15    error C2065: 'IterativeBootstrap' : undeclared identifier
> C:\quantliball\QuantLib-SWIG\CSharp\cpp\quantlib_wrap.cpp    7649    1
> NQuantLibc
>
>
> I understand that IterativeBootstrap itself is a template class and that’s
> probably the reason, but in test suite similar code compiles fine
> testCurveConsistency<ZeroYield,Cubic,IterativeBootstrap> ...
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] c++0x

[Mike S. <ma...@gm...>]

Hi Peter,

First off, thanks for taking a look at getting C++11 into a major project!

The line
    Clone(std::unique_ptr<T>& p);

looks suspicious to me. It doesn't make it clear from the client side that
the pointer ownership was changed. Compare the following three examples:
    // example 1
    std::unique_ptr<T> ptr(new T());
    Clone<T> newObject(ptr);
    // example 2
    std::unique_ptr<T> ptr(new T());
    Clone<T> newObject(std::move(ptr));
    //example 3
    Clone<T> newObject(std::unique_ptr<T>(new T()); // 3

Example 2 makes it obvious that the constructor will retain ownership of
the unique_ptr, which isn't obvious in example 1 even though the current
implementation means example 1 and example 2 are the same. In addition, the
current code will remove the ability for clients to use code like example 3
completely, as you can't bind a temporary object to a non-const lvalue
reference. It's possible clients could run into problems even if they don't
upgrade from auto_ptr to unique_ptr if they have code like this.

I propose that, instead of changing the function definition to incorporate
either auto_ptr or unique_ptr, that another Clone constructor is added, so
that there will be two constructors:

  Clone(std::auto_ptr<T> ptr);
#ifdef QL_UNIQUE_PTR_ENABLED
  Clone(std::unique_ptr<T> ptr);
#endif

The implementation of the auto_ptr constructor will need to make sure to
initialize the unique_ptr calling uniquePtr(std::move(autoPtr)) in the
initializer class if the internal class uses unique_ptr. This is
because unique_ptr has a constructor that accepts auto_ptr by rvalue
reference only, and rvalue references cannot bind to lvalues. But, you can
base the private data stored in clone off object internals simply off the
QL_UNIQUE_PTR_ENABLED #define, without clients having to change their code.
The decision to remove the auto_ptr constructor can be made later.

Hopefully this helps. Let me know if an updated Clone.hpp would make things
a little bit clearer and I can put something together when I have some time.

Mike


On Thu, May 30, 2013 at 9:13 AM, Peter Caspers <pca...@gm...>wrote:

> following up the topic below: I missed to look at the test-suite, where
> some more
> auto_ptr would have to be replaced by unique_ptr.
>
>
> https://github.com/pcaspers/quantlib/commit/466fbfbc423312eb7c4536ab59d861689cde70a0
>
> Furthermore the header ql/utilities/clone.hpp has to be changed.
>
>
> https://github.com/pcaspers/quantlib/commit/fe5a87dcfb60c10f1d8600b1511037e200915e4c
>
> https://github.com/pcaspers/quantlib/commit/7a12fc4c62b44d175dc794b487db0582803ef6a5
>
> The test-suite now compiles and runs using g++ (with and without
> -std=c++0x)
> which is the main thing I guess. The whole thing does not look very
> nice though. Also I am not c++ expert enough to say that the upgrade of
> clone.hpp to unique_ptr should be done like this. Luigi ?
>
> Thank you
>  Peter
>
> Peter Caspers <pca...@gm...> writes:
>
> > Hi Luigi, all,
> >
> > we discussed compiling the core lib under the c++11 standard (e.g. with
> > g++ -std=c++0x). This produces some errors which can be fixed easily
> > (keeping backward compatibility):
> >
> >
> https://github.com/pcaspers/quantlib/commit/5b32b7705530264551e0622d0a2673813067be5b
> >
> > What is left is a bunch of warnings saying that std::auto_ptr is
> > depricated under c++11, the replacement being std::unique_ptr. A
> > possible solution is to replace the auto_ptr in the source by unique_ptr
> > (thus upgrading the code to c++11 already) and replace the unique_ptr by
> > auto_ptr again in case that compilation is done under c++ versions <
> > 11. I have done this here
> >
> >
> https://github.com/pcaspers/quantlib/commit/3e47a82a936112f12e3bb502292833d860f5aac9
> >
> > with a #define in qldefines.hpp resetting the pointers to auto_ptr again
> > based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
> > macro is available only in later boost versions so if one uses an older
> > one and provides no c++11 support he or she will get errors. Therefore
> > the following solution might be better
> >
> >
> https://github.com/pcaspers/quantlib/commit/6db965375b02094a7ea0da4e48efd7e0a1b8fd85
> >
> > using the __cplusplus macro to identify c++11. However since gcc sets
> > this macro simply to 1 in versions 4.6 (should be solved starting in
> > 4.7), I had to add another criterion for gcc based on
> > __GXX_EXPERIMENTAL_CXX0X_.
> >
> > For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
> > seems also to be the case in 2012 and this specific case was reported as
> a bug to
> > Microsoft,
> >
> >
> http://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l
> >
> > though not solved yet. Therefore I added a direct test on msvc 2010 or
> > higher versions based on _MSC_VER
> >
> >
> https://github.com/pcaspers/quantlib/commit/796beb89e2a707f951b77869bf869694e67ac769
> >
> > This final solution should work for all versions of msvc and gcc. I can
> not check other
> > compilers however.
> >
> > Since the #define seems a bit like a dirty hack we also thought of a
> > typedef. But then we would need a template typedef which is available
> only in
> > c++11 again and a metaprogramming-like workaround a la
> >
> > template<class T> struct PTR {
> >     typedef std::unique_ptr<T> Type;
> > };
> >
> > PTR<double>::Type a(new double(0.0));
> >
> > does not seem to improve the code either.
> >
> > Do you think we should do the upgrade to c++11 like propsed above or is
> there
> > maybe a better solution (I bet there is...). Or should we defer the
> > upgrade until a later release ? I personally would very much like to be
> > able to compile under c++11 without warnings already now.
> >
> > Thank you
> >  Peter
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] VC9

[Mark j. <mar...@gm...>]

ok it seems to work, i have committed it.,

Mark



On 30 May 2013 20:33, Peter Caspers <pca...@gm...> wrote:

>  Hi Mark,
>
> can you please replace the file test-suite/markovfunctional.cpp with the
> attached one and see if it works then ?
>
>
> It seems map:at is not supported by vc9. Therefore I changed line 1015 as
> follows
>
> -        Real blackVega =
> boost::any_cast<Real>(ch1[i].additionalResults().at("vega"));
> +        Real blackVega = ch1[i].result<Real>("vega");
>
> and line 1075 respectively
>
> -        Real blackVega =
> boost::any_cast<Real>(ch2[i].additionalResults().at("vega"));
> +        Real blackVega = ch2[i].result<Real>("vega");
>
> regards
>  Peter
>
> Am 30.05.2013 08:27, schrieb Mark joshi:
>
>   OK I checked out and did a full build of QuantLib for the first time in
> a long time today.
>
>  The testsuite built and passed with VC11
>
>  With VC9 I get
>
> 1>.\markovfunctional.cpp(1015) : error C2039: 'at' : is not a member of
> 'std::map<_Kty,_Ty>'
> 1>        with
> 1>        [
> 1>            _Kty=std::string,
> 1>            _Ty=boost::any
> 1>        ]
>
>  Are we still targeting VC9?
>
> best
>
> Mark
>
>
> --
>
> Prof Mark Joshi
> Centre for Actuarial Studies
> University of Melbourne
> My website is www.markjoshi.com
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.http://p.sf.net/sfu/appdyn_d2d_ap1
>
>
>
> _______________________________________________
> QuantLib-dev mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
>
>


-- 

Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

[Quantlib-dev] How to correctly Extend swig PiecewiseYieldCurve.i

[Irakli M. <ima...@ho...>]

I tried to add thrd parameter Bootstrap type to  export_piecewise_curve like 
this

%define export_piecewise_curve(Name,Base,Interpolator,Bootstrap)

and then
export_piecewise_curve(PiecewiseFlatForward,ForwardRate,BackwardFlat,IterativeBootstrap);

Code produced by swig looks like this

SWIGINTERN PiecewiseFlatForwardPtr *new_PiecewiseFlatForwardPtr__SWIG_0(Date 
const &referenceDate,std::vector< boost::shared_ptr< RateHelper > > const 
&instruments,DayCounter const &dayCounter,std::vector< Handle< Quote > > 
const &jumps=std::vector< Handle< Quote > >(),std::vector< Date > const 
&jumpDates=std::vector< Date >(),Real accuracy=1.0e-12,BackwardFlat const 
&i=BackwardFlat()){
            return new PiecewiseFlatForwardPtr(
                new 
PiecewiseYieldCurve<ForwardRate,BackwardFlat,IterativeBootstrap>(
                                                 referenceDate,instruments,
                                                 dayCounter, jumps, 
jumpDates,
                                                 accuracy,i));
        }

And compiler curses

Error    7    error C3206: 'boost::dynamic_pointer_cast' : invalid template 
argument for 'T', missing template argument list on class template 
'QuantLib::PiecewiseYieldCurve' 
C:\quantliball\QuantLib-SWIG\CSharp\cpp\quantlib_wrap.cpp    7634    1 
NQuantLibc

Error    15    error C2065: 'IterativeBootstrap' : undeclared identifier 
C:\quantliball\QuantLib-SWIG\CSharp\cpp\quantlib_wrap.cpp    7649    1 
NQuantLibc


I understand that IterativeBootstrap itself is a template class and that’s 
probably the reason, but in test suite similar code compiles fine
testCurveConsistency<ZeroYield,Cubic,IterativeBootstrap> ...