quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Garch11 in Quantlib

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

Hi,
    at this time there's no code for calibration in the library (the
Garch11 class declares a calibrate method, but it's empty). If anyone
wants to contribute it, I'll be glad to add it to the repository.

Luigi

On Mon, May 14, 2012 at 7:25 PM, Yue Zhao <yzh...@gm...> wrote:
> My question might be silly. I am using the Garch11 class in QL, but I didn't
> see how to calibrate this model. Does anyone know how do calibration?

[Quantlib-dev] Garch11 in Quantlib

[Yue Z. <yzh...@gm...>]

Hi,

My question might be silly. I am using the Garch11 class in QL, but I
didn't see how to calibrate this model. Does anyone know how do calibration?

Best

Yue

[Quantlib-dev] [ quantlib-Bugs-3526577 ] BicubicSpline update() doesn't work

[SourceForge.net <no...@so...>]

Bugs item #3526577, was opened at 2012-05-14 07:26
Message generated for change (Tracker Item Submitted) made by fabioramponi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3526577&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Ramponi (fabioramponi)
Assigned to: Nobody/Anonymous (nobody)
Summary: BicubicSpline update() doesn't work

Initial Comment:
The calculate() method in BicubicSpline is called every time the linked data matrix (zData_) changes but, due to the reserve() at line 58 of bicubicsplineinterpolation.hpp and the subesquent push_back(), every time I call update() new splines are added to the splines_ vector instead of substituting the existing ones.

My suggestion is to use resize instead of reserve, and then simply fill the allocated vector splines_.

In the attached file my proposal of change for the file bicubicsplineinterpolation.hpp, affecting only lines 58 and 60.

Best regards,

Fabio

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3526577&group_id=12740

Re: [Quantlib-dev] Source control of Quantlib external development

[Ferdinando A. <na...@am...>]

On Mon, May 14, 2012 at 2:59 PM, Luigi Ballabio
<lui...@gm...> wrote:
> we'd have to think _how_ to switch.
> To begin with, do we stay on SourceForge or do we move the repository
> to GitHub? (Mailing lists and the site stay on SF, I guess).  And
> after that, do we put all the modules in one repository, or do we
> create one git repository per module?  (Unlike with subversion, it's
> not possible to checkout just part of a tree.)   And finally, what
> kind of workflow do we use?

we're all waiting for your wise proposal
:-D

Re: [Quantlib-dev] Source control of Quantlib external development

[Bojan N. <bo...@bn...>]

Luigi Ballabio <lui...@gm...> writes:

>     you can use git-svn to create a git repository 

Yes, we use git-svn too now. 

The bzr based solution stopped performing satisfactorily because of a
bug which I think is in libsvn but only seems to manifest when doing
bzr+svn.

Best,
Bojan


-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: [Quantlib-dev] Source control of Quantlib external development

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

On Mon, May 14, 2012 at 2:45 PM, Ferdinando Ametrano <na...@am...> wrote:
> would the scenario become clearer if we all switch to git?

Yes, of course.  The whole issue would become moot.

Then again, we'd have to think _how_ to switch.
To begin with, do we stay on SourceForge or do we move the repository
to GitHub? (Mailing lists and the site stay on SF, I guess).  And
after that, do we put all the modules in one repository, or do we
create one git repository per module?  (Unlike with subversion, it's
not possible to checkout just part of a tree.)   And finally, what
kind of workflow do we use?

Later,
    Luigi

> On Mon, May 14, 2012 at 1:10 PM, Luigi Ballabio
> <lui...@gm...> wrote:
>> Hi Simon,
>>    you can use git-svn to create a git repository on your machine
>> which is synced to the upstream QuantLib svn repository.  You can also
>> setup a cron job that keeps it up to date.  That way, you'd have a
>> mirror like the one I've put on github, but with the full repository
>> if you choose so.
>>
>> One issue with git-svn is that, of course, it can't really merge local
>> developments with upstream changes because subversion doesn't support
>> git merges.  This means that when you pull from upstream, it rebases
>> instead of merging.
>>
>> What you might do is probably to clone your mirror, use the clone as
>> your main repository, and never push from the clone to the mirror.
>> This way, when the mirror pulls from upstream svn it never has to
>> rebase; and when you pull from the mirror to the clone, you're dealing
>> with a git repository so you can merge your developments as usual.
>>
>> It's probably possible to do the same with mercurial, but I have never
>> tried having it talk to subversion.
>>
>> Luigi
>>
>>
>> On Mon, May 14, 2012 at 12:36 PM, Simon Ibbotson
>> <Sim...@fs...> wrote:
>>> Hi,
>>>
>>> I’ve been trying to work out the best way of maintaining my changes to the
>>> QuantLib code. Some of these changes will never be made public for a variety
>>> of reasons – but I still need to maintain a version control of these
>>> changes. Therefore, this version control will – of necessity – have to be
>>> outside Sourceforge.
>>>
>>> The approach advocated by Subversion would be to do vendor drops into a
>>> local repository – I’ve done this before but I lose the version history and
>>> it makes it difficult to merge changes (both my changes and Sourceforge
>>> changes).
>>>
>>> I see Bojan Nikolic has a blog where he talks about using Bazaar to do this
>>> - through the Launchpad service - but this appears to be currently
>>> suspended. I also see that Luigi has place a mirror of Quantlib trunk on
>>> github.com – but this does not appear to have QuantLibAddin or Excel
>>> interfaces.
>>>
>>> Can anyone give me some advice about which approach to take? Bazaar or Git
>>> (or some other technique).
>>>
>>> Even if you just reply with one sentence – telling me which approach you
>>> take – that would be very useful.
>>>
>>> Thanks,
>>>
>>> Simon
>>>
>>> Dr Simon Ibbotson
>>>
>>> Valuations: Modelling & Methodologies.
>>>
>>> Prudential Risk Division | Financial Services Authority
>>>
>>> Ext: 65586
>>>
>>> Email: Sim...@fs...
>>>
>>>
>>>
>>>
>>>
>>> This communication and any attachments contains information which is
>>> confidential and may be subject to legal privilege. It is for intended
>>> recipients only. If you are not the intended recipient you must not copy,
>>> distribute, publish, rely on or otherwise use it without our consent. Some
>>> of our communications may contain confidential information which it could be
>>> a criminal offence for you to disclose or use without authority. If you have
>>> received this email in error please notify pos...@fs... immediately
>>> and delete the email from your computer.
>>>
>>> The FSA reserves the right to monitor all email communications for
>>> compliance with legal, regulatory and professional standards.
>>>
>>> This email is not intended to nor should it be taken to create any legal
>>> relations or contractual relationships. This email has originated from
>>>
>>> The Financial Services Authority (FSA)
>>> 25 The North Colonnade,
>>> Canary Wharf,
>>> London
>>> E14 5HS
>>> United Kingdom
>>>
>>> Registered as a Limited Company in England and Wales No.1920623.
>>> Registered Office as above
>>>
>>> Switchboard: 020 7066 1000
>>> Web Site: http://www.fsa.gov.uk
>>> *****************************************************************
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Source control of Quantlib external development

[Ferdinando A. <na...@am...>]

would the scenario become clearer if we all switch to git?

On Mon, May 14, 2012 at 1:10 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Hi Simon,
>    you can use git-svn to create a git repository on your machine
> which is synced to the upstream QuantLib svn repository.  You can also
> setup a cron job that keeps it up to date.  That way, you'd have a
> mirror like the one I've put on github, but with the full repository
> if you choose so.
>
> One issue with git-svn is that, of course, it can't really merge local
> developments with upstream changes because subversion doesn't support
> git merges.  This means that when you pull from upstream, it rebases
> instead of merging.
>
> What you might do is probably to clone your mirror, use the clone as
> your main repository, and never push from the clone to the mirror.
> This way, when the mirror pulls from upstream svn it never has to
> rebase; and when you pull from the mirror to the clone, you're dealing
> with a git repository so you can merge your developments as usual.
>
> It's probably possible to do the same with mercurial, but I have never
> tried having it talk to subversion.
>
> Luigi
>
>
> On Mon, May 14, 2012 at 12:36 PM, Simon Ibbotson
> <Sim...@fs...> wrote:
>> Hi,
>>
>> I’ve been trying to work out the best way of maintaining my changes to the
>> QuantLib code. Some of these changes will never be made public for a variety
>> of reasons – but I still need to maintain a version control of these
>> changes. Therefore, this version control will – of necessity – have to be
>> outside Sourceforge.
>>
>> The approach advocated by Subversion would be to do vendor drops into a
>> local repository – I’ve done this before but I lose the version history and
>> it makes it difficult to merge changes (both my changes and Sourceforge
>> changes).
>>
>> I see Bojan Nikolic has a blog where he talks about using Bazaar to do this
>> - through the Launchpad service - but this appears to be currently
>> suspended. I also see that Luigi has place a mirror of Quantlib trunk on
>> github.com – but this does not appear to have QuantLibAddin or Excel
>> interfaces.
>>
>> Can anyone give me some advice about which approach to take? Bazaar or Git
>> (or some other technique).
>>
>> Even if you just reply with one sentence – telling me which approach you
>> take – that would be very useful.
>>
>> Thanks,
>>
>> Simon
>>
>> Dr Simon Ibbotson
>>
>> Valuations: Modelling & Methodologies.
>>
>> Prudential Risk Division | Financial Services Authority
>>
>> Ext: 65586
>>
>> Email: Sim...@fs...
>>
>>
>>
>>
>>
>> This communication and any attachments contains information which is
>> confidential and may be subject to legal privilege. It is for intended
>> recipients only. If you are not the intended recipient you must not copy,
>> distribute, publish, rely on or otherwise use it without our consent. Some
>> of our communications may contain confidential information which it could be
>> a criminal offence for you to disclose or use without authority. If you have
>> received this email in error please notify pos...@fs... immediately
>> and delete the email from your computer.
>>
>> The FSA reserves the right to monitor all email communications for
>> compliance with legal, regulatory and professional standards.
>>
>> This email is not intended to nor should it be taken to create any legal
>> relations or contractual relationships. This email has originated from
>>
>> The Financial Services Authority (FSA)
>> 25 The North Colonnade,
>> Canary Wharf,
>> London
>> E14 5HS
>> United Kingdom
>>
>> Registered as a Limited Company in England and Wales No.1920623.
>> Registered Office as above
>>
>> Switchboard: 020 7066 1000
>> Web Site: http://www.fsa.gov.uk
>> *****************************************************************
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Source control of Quantlib external development

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

Hi Simon,
    you can use git-svn to create a git repository on your machine
which is synced to the upstream QuantLib svn repository.  You can also
setup a cron job that keeps it up to date.  That way, you'd have a
mirror like the one I've put on github, but with the full repository
if you choose so.

One issue with git-svn is that, of course, it can't really merge local
developments with upstream changes because subversion doesn't support
git merges.  This means that when you pull from upstream, it rebases
instead of merging.

What you might do is probably to clone your mirror, use the clone as
your main repository, and never push from the clone to the mirror.
This way, when the mirror pulls from upstream svn it never has to
rebase; and when you pull from the mirror to the clone, you're dealing
with a git repository so you can merge your developments as usual.

It's probably possible to do the same with mercurial, but I have never
tried having it talk to subversion.

Luigi


On Mon, May 14, 2012 at 12:36 PM, Simon Ibbotson
<Sim...@fs...> wrote:
> Hi,
>
> I’ve been trying to work out the best way of maintaining my changes to the
> QuantLib code. Some of these changes will never be made public for a variety
> of reasons – but I still need to maintain a version control of these
> changes. Therefore, this version control will – of necessity – have to be
> outside Sourceforge.
>
> The approach advocated by Subversion would be to do vendor drops into a
> local repository – I’ve done this before but I lose the version history and
> it makes it difficult to merge changes (both my changes and Sourceforge
> changes).
>
> I see Bojan Nikolic has a blog where he talks about using Bazaar to do this
> - through the Launchpad service - but this appears to be currently
> suspended. I also see that Luigi has place a mirror of Quantlib trunk on
> github.com – but this does not appear to have QuantLibAddin or Excel
> interfaces.
>
> Can anyone give me some advice about which approach to take? Bazaar or Git
> (or some other technique).
>
> Even if you just reply with one sentence – telling me which approach you
> take – that would be very useful.
>
> Thanks,
>
> Simon
>
> Dr Simon Ibbotson
>
> Valuations: Modelling & Methodologies.
>
> Prudential Risk Division | Financial Services Authority
>
> Ext: 65586
>
> Email: Sim...@fs...
>
>
>
>
>
> This communication and any attachments contains information which is
> confidential and may be subject to legal privilege. It is for intended
> recipients only. If you are not the intended recipient you must not copy,
> distribute, publish, rely on or otherwise use it without our consent. Some
> of our communications may contain confidential information which it could be
> a criminal offence for you to disclose or use without authority. If you have
> received this email in error please notify pos...@fs... immediately
> and delete the email from your computer.
>
> The FSA reserves the right to monitor all email communications for
> compliance with legal, regulatory and professional standards.
>
> This email is not intended to nor should it be taken to create any legal
> relations or contractual relationships. This email has originated from
>
> The Financial Services Authority (FSA)
> 25 The North Colonnade,
> Canary Wharf,
> London
> E14 5HS
> United Kingdom
>
> Registered as a Limited Company in England and Wales No.1920623.
> Registered Office as above
>
> Switchboard: 020 7066 1000
> Web Site: http://www.fsa.gov.uk
> *****************************************************************
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Source control of Quantlib external development

[Simon I. <Sim...@fs...>]

Hi,

I've been trying to work out the best way of maintaining my changes to
the QuantLib code. Some of these changes will never be made public for a
variety of reasons - but I still need to maintain a version control of
these changes. Therefore, this version control will - of necessity -
have to be outside Sourceforge.

The approach advocated by Subversion would be to do vendor drops into a
local repository - I've done this before but I lose the version history
and it makes it difficult to merge changes (both my changes and
Sourceforge changes).

I see Bojan Nikolic has a blog where he talks about using Bazaar to do
this - through the Launchpad service - but this appears to be currently
suspended. I also see that Luigi has place a mirror of Quantlib trunk on
github.com - but this does not appear to have QuantLibAddin or Excel
interfaces.

Can anyone give me some advice about which approach to take? Bazaar or
Git (or some other technique).

Even if you just reply with one sentence - telling me which approach you
take - that would be very useful.

Thanks,
Simon



Dr Simon Ibbotson
Valuations: Modelling & Methodologies.
Prudential Risk Division | Financial Services Authority
Ext: 65586
Email: Sim...@fs...
 




This communication and any attachments contains information which is confidential and may be subject to legal privilege. It is for intended recipients only. If you are not the intended recipient you must not copy, distribute, publish, rely on or otherwise use it without our consent. Some of our communications may contain confidential information which it could be a criminal offence for you to disclose or use without authority. If you have received this email in error please notify pos...@fs... immediately and delete the email from your computer.

The FSA reserves the right to monitor all email communications for compliance with legal, regulatory and professional standards.
This email is not intended to nor should it be taken to create any legal relations or contractual relationships. This email has originated from

The Financial Services Authority (FSA)
25 The North Colonnade,
Canary Wharf,
London
E14 5HS
United Kingdom

Registered as a Limited Company in England and Wales No.1920623.
Registered Office as above

Switchboard: 020 7066 1000
Web Site: http://www.fsa.gov.uk
*****************************************************************

[Quantlib-dev] [ quantlib-Bugs-3525797 ] OIS Coupon calculation

[SourceForge.net <no...@so...>]

Bugs item #3525797, was opened at 2012-05-11 03:31
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3525797&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andre Miemiec (miemiec)
>Assigned to: Luigi Ballabio (lballabio)
Summary: OIS Coupon calculation 

Initial Comment:
I came across a tiny bug in the computation of overnight index coupons. In the file overnightindexcoupon.cpp the funtion swapletRate has a while slope
of type while( fixingDates[i]<today && i<n). When you try to compute the coupon on the payment date than the condition i<n is not satified but the access in fixingDates[i] is executed before. The program crahes.  

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2012-05-14 03:18

Message:
The bug is now fixed in the Subversion repository.
Thank you for the report.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3525797&group_id=12740

Re: [Quantlib-dev] fd questions ctd...

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

Hi Klaus,

yes, I totally agree. Concerning the time dependent Dirichlet bc I guess 
one should insert a

bc->setTime( t );

before each call of applyAfterApplying(Array&), 
applyAfterSolving(Array&) or applyAfterApplying(Real,Real) to ensure 
that valueOnBoundaryTimeDep_ / valuesOnBoundaryTimeDep_ are correctly 
set. No?

Concerning the Neumann bc, I was too optimistic about what has to be 
done to adapt the existing operators. You are right, it is not enough to 
provide discretizations for the base operators in the general case. It 
works fine in my toy example but it is useless otherwise. Sorry I should 
have spent some more thoughts on this.

I will be happy if you find the Dirichlet bc extension useful and add it 
to the SVN. I will also continue to think about the Neumann bc and try 
to send more useful code next time ;-)

thank you again and regards
Peter

Am 10.05.2012 23:16, schrieb Klaus Spanderen:
> Hi Peter,
>
> cool stuff. The Dirichlet bc was introduced to implement barrier options only.
> Your time dependent code the right step forward..and yes, the implementation
> of the schemes is based on either free bc's or non time dependent Dirichlet
> bc's. This is also the main reason why FdmBoundaryConditionSet is linked to
> FdmDirichletBoundary instead of OperatorTraits<FdmLinearOp>::bc_set. One
> think we still need to do is to make
>
> FdmDirichletBoundary::applyAfterApplying(Real x, Real value) const;
>
> time dependent as well.
>
> As you have written It's difficult to implement the Neumann bc in a general
> manner for the multi dimensional framework. In the one dim. framework all
> linear operators are tridiagonal operators and the Neumann bc is "doable". I
> have no idea how to translate this idea into the multi dimensional case
> except implementing the Neumann bc for all 10+ operators individually. (hmm..
> I don't think it is enough to do this for the three basis operators alone).
>
>> Needless to say that I am totally not sure if I did that correctly.
> good question. I haven't seen much in the literature on the topic "Neumann bc
> and operator splitting". I think we'll also at least need to call
> applyBeforeSolving in the schemes for the Neumann bc case.
>
> IMO the Neumann bc task will take a bit longer. Shall we first lift the time
> dependent Dirichlet bc to the QL 1.2 file structure and add this to SVN?
>
> regards
>   Klaus
>
>
> On Sunday 06 May 2012 21:24:39 Peter Caspers wrote:
>> Hallo Klaus,
>>
>> thanks a lot for your answers. I implemented a Neumann condition for the
>> multidimensional case. I tested the new class against known solutions
>> for the 1d heat equation with Neumann and mixed lower Dirichlet / upper
>> Neumann conditions using some of the existing multidim schemes. The
>> results suggest that the implementation is ok. Also, the testsuite runs
>> without problems which is good I guess.
>>
>> However, I could not see how to implement the condition by changing the
>> final operator directly as done in the 1d framework. Instead I added
>> functionality to change the discretization of multidim operators from
>> default = FreeBoundary to Neumann by adding a method
>>
>> void FdmLinearOp::discretization(Size direction, Discretization d);
>>
>> The enum DiscretizationType in the same class can be used to specify a
>> Neumann discretization together with the side (using bitwise or; this
>> could be extended for other boundary conditions later). The method calls
>> another protected virtual method changeDiscretization(...) which should
>> be implemented by user defined operators. I did not do that for the
>> existing operators yet (in case I am on the wrong road with my
>> approach), but rather added a test operator FdmHeat1dOp (representing
>> the pde u_t = \alpha u_xx) which demonstrates the principle. The
>> required extension of operators can easily be done being supported by
>> extended constructors of the 'basis' operators (first, second and mixed
>> second derivatives) allowing for Neumann discretization now. I think I
>> did that discretization in the standard way, but it should be cross
>> checked.
>>
>> I amended the scheme implementations w.r.t. their calls to the
>> apply...() methods having the impression that these accounted for the
>> Dirichlet case only so far. Needless to say that I am totally not sure
>> if I did that correctly. Since I also extended the Dirichlet condition
>> to the time (and spatial) dependent case, I inserted the needed
>> setTime() calls in the schemes accordingly. In the Dirichlet condition
>> itself I implemented the applyBeforeSolving() method because I think it
>> is necessary for the time dependent case (and comparisions to known 1d
>> heat equation solutions do confirm this).
>>
>> I removed the FdmBoundaryConditionSet typedef from the multidim
>> Dirichlet condition, instead refering to
>> OperatorTraits<FdmLinearOp>::bc_set in the schemes, solvers, engines and
>> operators now. There is a applyAfterApplying(Real,Real) method in the
>> Dirichlet condition (used in some engine I think) which I added to the
>> general interface (by default throwing an exception to ensure that only
>> the implementation in the Dirichlet boundary is actually used).
>>
>> Finally I amended the concentrating1dmesher once again because I noted
>> that it throws an exception when QL_EXTRA_SAFETY_CHECKS are enabled and
>> the concentrating point is equal to one of the endpoints (this having to
>> do with an extra check concerning the strict order of x values in
>> interpolation.hpp).
>>
>> I attach my changes (zips with changed files as per directory and new
>> files attached directly, all based on ql 1.1) and would be happy if you
>> could have a look.
>>
>> Thank you
>> Peter
>>

[Quantlib-dev] Yield Curve fitting with OIS/Libor, Stochastic vol/Stochastic rates

[<tb...@ao...>]

Hi Luigi,
 I am looking at piecewiseyieldcurve.cpp in testsuite, I have the following
uestions:
 (a) what is BMA?
(b) what does this code below do, RelinkableHandle<YieldTermStructure>
curveHandle;curveHandle.linkTo(vars.termStructure);
(c) Is there any code boostrapping OIS and Libor simultaneously, as that
seems to be the way now for yieldcurve building and fitting and I want to
understand how that works.
 (d) Is there any thing on hybrids eg. FX/IR ie PRDC or EQ/IR where rates is
long-dated so using say Heston or Bates Stochastic vol model with Stochastic rates using Hull/White?
Regards
Theo

[Quantlib-dev] [ quantlib-Bugs-3525797 ] OIS Coupon calculation

[SourceForge.net <no...@so...>]

Bugs item #3525797, was opened at 2012-05-11 03:31
Message generated for change (Tracker Item Submitted) made by miemiec
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3525797&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andre Miemiec (miemiec)
Assigned to: Nobody/Anonymous (nobody)
Summary: OIS Coupon calculation 

Initial Comment:
I came across a tiny bug in the computation of overnight index coupons. In the file overnightindexcoupon.cpp the funtion swapletRate has a while slope
of type while( fixingDates[i]<today && i<n). When you try to compute the coupon on the payment date than the condition i<n is not satified but the access in fixingDates[i] is executed before. The program crahes.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3525797&group_id=12740

Re: [Quantlib-dev] fd questions ctd...

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

Hi Peter,

cool stuff. The Dirichlet bc was introduced to implement barrier options only. 
Your time dependent code the right step forward..and yes, the implementation 
of the schemes is based on either free bc's or non time dependent Dirichlet 
bc's. This is also the main reason why FdmBoundaryConditionSet is linked to 
FdmDirichletBoundary instead of OperatorTraits<FdmLinearOp>::bc_set. One 
think we still need to do is to make
 
FdmDirichletBoundary::applyAfterApplying(Real x, Real value) const;

time dependent as well.

As you have written It's difficult to implement the Neumann bc in a general 
manner for the multi dimensional framework. In the one dim. framework all 
linear operators are tridiagonal operators and the Neumann bc is "doable". I 
have no idea how to translate this idea into the multi dimensional case 
except implementing the Neumann bc for all 10+ operators individually. (hmm.. 
I don't think it is enough to do this for the three basis operators alone).

> Needless to say that I am totally not sure if I did that correctly. 

good question. I haven't seen much in the literature on the topic "Neumann bc 
and operator splitting". I think we'll also at least need to call 
applyBeforeSolving in the schemes for the Neumann bc case.

IMO the Neumann bc task will take a bit longer. Shall we first lift the time 
dependent Dirichlet bc to the QL 1.2 file structure and add this to SVN?

regards
 Klaus


On Sunday 06 May 2012 21:24:39 Peter Caspers wrote:
> Hallo Klaus,
>
> thanks a lot for your answers. I implemented a Neumann condition for the
> multidimensional case. I tested the new class against known solutions
> for the 1d heat equation with Neumann and mixed lower Dirichlet / upper
> Neumann conditions using some of the existing multidim schemes. The
> results suggest that the implementation is ok. Also, the testsuite runs
> without problems which is good I guess.
>
> However, I could not see how to implement the condition by changing the
> final operator directly as done in the 1d framework. Instead I added
> functionality to change the discretization of multidim operators from
> default = FreeBoundary to Neumann by adding a method
>
> void FdmLinearOp::discretization(Size direction, Discretization d);
>
> The enum DiscretizationType in the same class can be used to specify a
> Neumann discretization together with the side (using bitwise or; this
> could be extended for other boundary conditions later). The method calls
> another protected virtual method changeDiscretization(...) which should
> be implemented by user defined operators. I did not do that for the
> existing operators yet (in case I am on the wrong road with my
> approach), but rather added a test operator FdmHeat1dOp (representing
> the pde u_t = \alpha u_xx) which demonstrates the principle. The
> required extension of operators can easily be done being supported by
> extended constructors of the 'basis' operators (first, second and mixed
> second derivatives) allowing for Neumann discretization now. I think I
> did that discretization in the standard way, but it should be cross
> checked.
>
> I amended the scheme implementations w.r.t. their calls to the
> apply...() methods having the impression that these accounted for the
> Dirichlet case only so far. Needless to say that I am totally not sure
> if I did that correctly. Since I also extended the Dirichlet condition
> to the time (and spatial) dependent case, I inserted the needed
> setTime() calls in the schemes accordingly. In the Dirichlet condition
> itself I implemented the applyBeforeSolving() method because I think it
> is necessary for the time dependent case (and comparisions to known 1d
> heat equation solutions do confirm this).
>
> I removed the FdmBoundaryConditionSet typedef from the multidim
> Dirichlet condition, instead refering to
> OperatorTraits<FdmLinearOp>::bc_set in the schemes, solvers, engines and
> operators now. There is a applyAfterApplying(Real,Real) method in the
> Dirichlet condition (used in some engine I think) which I added to the
> general interface (by default throwing an exception to ensure that only
> the implementation in the Dirichlet boundary is actually used).
>
> Finally I amended the concentrating1dmesher once again because I noted
> that it throws an exception when QL_EXTRA_SAFETY_CHECKS are enabled and
> the concentrating point is equal to one of the endpoints (this having to
> do with an extra check concerning the strict order of x values in
> interpolation.hpp).
>
> I attach my changes (zips with changed files as per directory and new
> files attached directly, all based on ql 1.1) and would be happy if you
> could have a look.
>
> Thank you
> Peter
>

[Quantlib-dev] Boost 1.44 onwards

[Simon I. <Sim...@fs...>]

One issue I've discovered is that Boost Filesystem has been radically
changed in later versions. Versions 1.46 and 1.47 are backward
compatible if you include the macro "BOOST_FILESYSTEM_VERSION=2".

>From version 1.48, the QuantLib use of Boost Filesystem will not work
and may have to change (or include macro defined code).

All the best,
Simon





This communication and any attachments contains information which is confidential and may be subject to legal privilege. It is for intended recipients only. If you are not the intended recipient you must not copy, distribute, publish, rely on or otherwise use it without our consent. Some of our communications may contain confidential information which it could be a criminal offence for you to disclose or use without authority. If you have received this email in error please notify pos...@fs... immediately and delete the email from your computer.

The FSA reserves the right to monitor all email communications for compliance with legal, regulatory and professional standards.
This email is not intended to nor should it be taken to create any legal relations or contractual relationships. This email has originated from

The Financial Services Authority (FSA)
25 The North Colonnade,
Canary Wharf,
London
E14 5HS
United Kingdom

Registered as a Limited Company in England and Wales No.1920623.
Registered Office as above

Switchboard: 020 7066 1000
Web Site: http://www.fsa.gov.uk
*****************************************************************

Re: [Quantlib-dev] How all.hpp files are called on visual c++

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

On Thu, May 3, 2012 at 11:12 PM, MoonDragon <phi...@gm...> wrote:
> I would like to know how the files all.hpp are called (since they are
> automatically generated) and what is there purpose.

They were added as a convenience.  If you include an all.hpp folder,
it recursively includes all the headers in the same directory and
those in its subdirectories.  You can use it when you want to write
some code quickly and you don't want to enumerate all the specific
#include you need.  However, be aware that it causes the compilation
times to go up, since you might be including quite some stuff you
don't need.

Luigi

Re: [Quantlib-dev] Local static initialization in singleton.hpp

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

Hi William,
    apologies for the delay.  We've had another contribution recently
on the singleton issue, that applies the same patch and also addresses
the problem of managing the session-id function at runtime.  The diffs
are at <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>;
it would be great if you (and anyone interested) could have a look and
comment.

Thanks,
    Luigi


On Wed, Apr 18, 2012 at 12:20 AM, W. Anthony Calore
<ant...@gm...> wrote:
> Hi all,
>
> I was looking at the thread-safety bug identified in singleton.hpp. To fix
> this bug I thought to throw a lock on a class static boost::mutex into the
> template class function singleton<t>::instance() to serialize access to
> instances_
>
> +      boost::mutex::scoped_lock lock(mutex_);
>         boost::shared_ptr<T>& instance = instances_[id];
>
> Since instances_ is a local static, it's probably important to point out
> that its initialization is not necessarily thread-safe depending on the
> compiler in use. I pretty much ignored that problem entirely.
>
> Also, to use boost/thread.hpp, the boost/bind.hpp header gets included,
> which adds additional placeholders to the global namespace.
>
> The effect this would have is that using the inclusion of boost/bind.hpp
> requires you to add qualifiers to the
> /ql/pricingengines/vanilla/analytichestonengine.cpp such that every
> reference to the placeholder _1 becomes boost::lambda::_1  . Otherwise
> you'll get compile-time errors for ambiguous reference
>
> It turns out that this is the only place where that caused a naming
> collision.
>
> This would be kind of a weird change and I have never submitted any patches
> for this project so I thought I'd ask the list for its thoughts.

[Quantlib-dev] QuantLib SWIG - optionlet stripper

[<tar...@li...>]

Hello, 

I have correctly ported QuantLib into Java using SWIG but only a part of the 
whole list of functionalities are translated. In fact the .i files do not 
consider all the QL files. 
I would like to know if someone has already implemented the interface for  the 
OptionletStripper.

If yes I would appreciate if you can forward me so I can give it a look in 
details

Thanks
Paolo

Re: [Quantlib-dev] QuantLib with Python without compiler

[Didrik P. <dp...@en...>]

On 4 May 2012 22:37, Glauner, Tim <Tim...@mi...> wrote:
> Is there any way that I can use the SWIG Python wrapper for QuantLib without
> having to compile the wrapper. It seems that the download always requires me
> to build the wrapper.
>

The only way would be to have some guys taking care of building and
distributing the wrappers on their website. This is something I plan
to do for PyQL. We might consider adding the SWIG bindings too. What
is the target platform ?

-- Didrik

Re: [Quantlib-dev] fd questions ctd...

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

Hallo Klaus,

thanks a lot for your answers. I implemented a Neumann condition for the 
multidimensional case. I tested the new class against known solutions 
for the 1d heat equation with Neumann and mixed lower Dirichlet / upper 
Neumann conditions using some of the existing multidim schemes. The 
results suggest that the implementation is ok. Also, the testsuite runs 
without problems which is good I guess.

However, I could not see how to implement the condition by changing the 
final operator directly as done in the 1d framework. Instead I added 
functionality to change the discretization of multidim operators from 
default = FreeBoundary to Neumann by adding a method

void FdmLinearOp::discretization(Size direction, Discretization d);

The enum DiscretizationType in the same class can be used to specify a 
Neumann discretization together with the side (using bitwise or; this 
could be extended for other boundary conditions later). The method calls 
another protected virtual method changeDiscretization(...) which should 
be implemented by user defined operators. I did not do that for the 
existing operators yet (in case I am on the wrong road with my 
approach), but rather added a test operator FdmHeat1dOp (representing 
the pde u_t = \alpha u_xx) which demonstrates the principle. The 
required extension of operators can easily be done being supported by 
extended constructors of the 'basis' operators (first, second and mixed 
second derivatives) allowing for Neumann discretization now. I think I 
did that discretization in the standard way, but it should be cross checked.

I amended the scheme implementations w.r.t. their calls to the 
apply...() methods having the impression that these accounted for the 
Dirichlet case only so far. Needless to say that I am totally not sure 
if I did that correctly. Since I also extended the Dirichlet condition 
to the time (and spatial) dependent case, I inserted the needed 
setTime() calls in the schemes accordingly. In the Dirichlet condition 
itself I implemented the applyBeforeSolving() method because I think it 
is necessary for the time dependent case (and comparisions to known 1d 
heat equation solutions do confirm this).

I removed the FdmBoundaryConditionSet typedef from the multidim 
Dirichlet condition, instead refering to 
OperatorTraits<FdmLinearOp>::bc_set in the schemes, solvers, engines and 
operators now. There is a applyAfterApplying(Real,Real) method in the 
Dirichlet condition (used in some engine I think) which I added to the 
general interface (by default throwing an exception to ensure that only 
the implementation in the Dirichlet boundary is actually used).

Finally I amended the concentrating1dmesher once again because I noted 
that it throws an exception when QL_EXTRA_SAFETY_CHECKS are enabled and 
the concentrating point is equal to one of the endpoints (this having to 
do with an extra check concerning the strict order of x values in 
interpolation.hpp).

I attach my changes (zips with changed files as per directory and new 
files attached directly, all based on ql 1.1) and would be happy if you 
could have a look.

Thank you
Peter


Am 23.04.2012 13:08, schrieb Klaus Spanderen:
> Hi Peter
>
> 1. Thanks for your changes, I've added the new class to the SVN trunk.
>
> 2. At the time being I think the answer is no. We'll have to extend
>   ql/methods/finitedifferences/FiniteDifferenceModel::rollbackImpl
> by the capability to deal with non uniform time grids.
>
> 3. I've used FiniteDifferenceModel::rollback to solve the Fokker-Planck
> equation. Even though the name of the method is "rollback", if "from is
> smaller than to" the methods rolls forward. You'll have to remove line 95 and
> 96
>
>              QL_REQUIRE(from>= to,
>                         "trying to roll back from "<<  from<<  " to "<<  to);
>
> from finitedifferencemodel.hpp to get it working.
>
> 4. The multidim frameworks supports "free boundary condition" (default if no
> BC is given) and Dirichlet BC. Your are right, the Neumann condition was
> never implemented. The boundary conditions are hardcoded in some classes
> because otherwise users might supply the one dimensional classes NeumannBC or
> DirichletBC, which don't work in the multidimensional case. If you have a
> multidimensional version of NeumannBC running we can change the interfaces.
>
> regards
>   Klaus
>
> On Sunday 22 April 2012 19:27:12 Peter Caspers wrote:
>> Hi,
>>
>> may I ask one more question please:
>>
>> 4. it seems there is only a Dirichlet boundary condition implemented in
>> the multi dimensional context. I want a Neumann condition and I think I
>> managed to implement a version, but the boundary conditions are
>> hardcoded as FdmDirichletBoundary in many classes, even the typedef for
>> the FdmBoundaryConditionSet is vector<shared_ptr<FdmDirichletBoundary>>.
>> Am I missing something here? How else would I be supposed to add new
>> boundary conditions?
>>
>> As for 1. below I extended the concentrating mesher by a flag that
>> allows the central point to be forced into the mesh (using a piecewise
>> linear transformation of the generating uniform grid, see e.g. Iain
>> Clarke, FX Option Pricing, ch. ...). To set up non uniform grids with
>> more than one concentrating point I added the glued1dmesher. If you
>> consider these contributions useful, please add them to the library.
>>
>> 2 and 3 have obvious workarounds (rewriting the pde as backward and
>> doing the time steps manually one by one). Still the implementation of
>> forward operators becomes less readable by this implicit (yet trivial)
>> transformation and possibly it may be useful in general to have a non
>> uniform time grid in the solvers, e.g. via a transformation [0,1] ->
>> [0,1], u ->  pow(u,alpha), alpha>  0 and a linear one [0,1] ->  [0,T] (cf.
>> same reference as above). If considered useful, I'd be happy to do these
>> extensions to the FdmBackwardSolver class.
>>
>> Regards
>> Peter
>>
>> -------- Original-Nachricht --------
>> Betreff: 	[Quantlib-users] fd questions
>> Datum: 	Thu, 12 Apr 2012 13:37:25 +0200
>> Von: 	Peter Caspers<pca...@vo...>
>> An: 	qua...@li...
>>
>>
>>
>> Hi,
>>
>> I just started to use the ql 1.1 / finitedifferences framework and have
>> a couple of (probably very basic) questions:
>>
>> 1. Is there a way to specify a or even several mandatory point(s) in the
>> meshers?
>> 2. Can I use a non uniform time grid in the solver?
>> 3. Is there a forward solver ?
>>
>> Thank you
>> Peter
>>
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] QuantLib with Python without compiler

[Glauner, T. <Tim...@mi...>]

Is there any way that I can use the SWIG Python wrapper for QuantLib
without having to compile the wrapper. It seems that the download always
requires me to build the wrapper. 
 
Thanks very much,
Tim


"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/corp/About_Us/misys_operating_companies.html. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [Quantlib-dev] Bootstrapping Caplet Volas from ATM Cap/Floor Volas

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

Hi Andreas,

when I try something like this


     boost::shared_ptr<YieldTermStructure> yts(new 
FlatForward(0,TARGET(),0.05,Actual365Fixed()));
     boost::shared_ptr<IborIndex> euribor6m(new 
Euribor(6*Months,Handle<YieldTermStructure>(yts)));
     std::vector<Period> optionTenors;
     optionTenors.push_back(1*Years);
     optionTenors.push_back(2*Years);
     optionTenors.push_back(3*Years);
     optionTenors.push_back(4*Years);
     optionTenors.push_back(5*Years);
     std::vector<Rate> strikes;
     strikes.push_back(0.03);
     strikes.push_back(0.04);
     strikes.push_back(0.05);
     strikes.push_back(0.06);
     strikes.push_back(0.07);
     Matrix flatVols(5,5,0.20);
     boost::shared_ptr<CapFloorTermVolSurface> caps(new 
CapFloorTermVolSurface(0,TARGET(),ModifiedFollowing,optionTenors,strikes,flatVols));
     boost::shared_ptr<OptionletStripper> stripper(new 
OptionletStripper1(caps,euribor6m));
     boost::shared_ptr<OptionletVolatilityStructure> caplets(new 
StrippedOptionletAdapter(stripper));
     for(int i=0;i<strikes.size();i++) {
         for(int j=0;j<10;j++) {
             std::cout << caplets->volatility(j*6*Months,strikes[i]) << " ";
         }
         std::cout << std::endl;
     }


I get


0.199999 0.2 0.2 0.2 0.2 0.20006 0.200001 0.2 0.200018 0.2
0.199999 0.199999 0.2 0.2 0.2 0.200091 0.200001 0.2 0.200025 0.2
0.2 0.2 0.2 0.2 0.2 0.199817 0.199998 0.2 0.199949 0.2
0.2 0.2 0.2 0.2 0.2 0.199881 0.199999 0.2 0.199965 0.2
0.2 0.2 0.2 0.2 0.2 0.199911 0.199999 0.2 0.199973 0.2


which looks reasonable. Is that of any help for you?

Regards
Peter


Am 04.05.2012 10:00, schrieb Andreas Spengler:
> Hi,
>
> I am currently using QL in a project to price Structured Floaters; as part
> of the incoming data I would like to use to parameterize the LFM we are
> receiving (annualized) atm cap/floor volatilities...
>
> I tried using OptionletStripper1/2 to get caplet volas from those;
> however, OptionletStripper2 is not usable since it relies on
> OptionletStripper1 which in turn needs a vol surface instead of a vol curve.
>
> Anyhow, "faking" a vol surface by setting all values (in strike dimension)
> to the atm vols returned only zeros upon calling
> OptionletStripper1::optionletVolatilities()
>
> Am I doing something fundementally wrong here and/or is there some other
> class/method which I can use for the purpose?
>
>
> Thanks for any help and best regards,
>
> Andreas
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Bootstrapping Caplet Volas from ATM Cap/Floor Volas

[Andreas S. <an...@sp...>]

Hi,

I am currently using QL in a project to price Structured Floaters; as part
of the incoming data I would like to use to parameterize the LFM we are
receiving (annualized) atm cap/floor volatilities...

I tried using OptionletStripper1/2 to get caplet volas from those;
however, OptionletStripper2 is not usable since it relies on
OptionletStripper1 which in turn needs a vol surface instead of a vol curve.

Anyhow, "faking" a vol surface by setting all values (in strike dimension)
to the atm vols returned only zeros upon calling
OptionletStripper1::optionletVolatilities()

Am I doing something fundementally wrong here and/or is there some other
class/method which I can use for the purpose?


Thanks for any help and best regards,

Andreas

[Quantlib-dev] [ quantlib-Bugs-3520550 ] Possible bug in rounding.cpp?

[SourceForge.net <no...@so...>]

Bugs item #3520550, was opened at 2012-04-23 01:24
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3520550&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: simon_shakeshaft ()
>Assigned to: Luigi Ballabio (lballabio)
Summary: Possible bug in rounding.cpp?

Initial Comment:
Hello,

Applying UpRouding to 0.86313 with precision set to 5 produces 0.86314.  Assuming this behaviour is not 'by-design' then I've attached suggested patch files for ql/math/rouding.cpp and an additional test case in /test-suite/rounding.cpp.

Regards
Simon Shakeshaft

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2012-05-03 23:58

Message:
The patch was applied to the Subversion repository.
Thank you for the report and the fix.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3520550&group_id=12740

[Quantlib-dev] How all.hpp files are called on visual c++

[MoonDragon <phi...@gm...>]

Hi,

I would like to know how the files all.hpp are called (since they are
automatically generated) and what is there purpose.

Thanks and regards,

MoonDragon
-- 
View this message in context: http://old.nabble.com/How-all.hpp-files-are-called-on-visual-c%2B%2B-tp33763430p33763430.html
Sent from the quantlib-dev mailing list archive at Nabble.com.