quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] SWIG R with c++11

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

no, it's solved, see my other mail. It only seems that the compiled wrapper
is not generated during the build. Of course I can do it myself
afterwards though.
   Thank you.

Joseph Wang <joe...@gm...> writes:

> Can you e-mail me the log files?  It should be a pretty
> straightforward matter to make it work with C++11.

[Quantlib-dev] Fixes to quantlib push #45 / openmp

[Joseph W. <joe...@gm...>]

I've revised quantlib push #45 to default openmp to off, and to include
only parallel changes that don't cause numerical differences.  Can you take
a look and see if you can push it into the main quantlib trunk.

Also, I'd be interested to what experiences people out there have with
openmp.  I'm finding that it dramatically speeds up FD and lattice
calculations in my six-core machine.

[Quantlib-dev] SWIG R with c++11

[Joseph W. <joe...@gm...>]

Can you e-mail me the log files?  It should be a pretty straightforward
matter to make it work with C++11.

Re: [Quantlib-dev] SWIG R with c++11

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

Hi Dirk,

thank you. With

CXX=clang++
CXXFLAGS=-g -O3 -Wall -pipe -Wno-unused -pedantic -std=c++11

in ~/R/Makevars make runs smooth on my code. I get 12 warnings of type

QuantLib.cpp:552:7: warning: 'register' storage class specifier is deprecated [-Wdeprecated-register]

which does not look critical, and 3 warnings 

* checking DESCRIPTION meta-information ... WARNING
Non-standard license specification:
  QuantLib License
Standardizable: FALSE

* checking for missing documentation entries ... WARNING
Undocumented code objects:
  ‘ARSCurrency’ ‘ATSCurrency’ ‘AUDCurrency’ ‘AUDLibor’
  ‘AUDLibor__SWIG_0’ ‘AUDLibor__SWIG_1’ ‘Actual360’ ‘Actual365Fixed’
  ‘Actual365NoLeap’ ‘ActualActual’ ‘ActualActual__SWIG_0’
...

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.

again not dangerous, are they. 

Also then running R CMD INSTALL . goes without problems. After that I
have a QuantLib.so which I can load from R

dyn.load('/usr/local/lib/R/site-library/QuantLib/libs/QuantLib.so')

and after

source('~/quantlibpc/QuantLib-SWIG/R/R/QuantLib.R')

I can succesfully run a few basic tests with QuantLib objects.

However there does not seem to be the compiled wrapper QuantLib.RData
generated. Was it renamed maybe or do I have to generate it by myself ?

Thanks a lot
    Peter

Dirk Eddelbuettel <ed...@de...> writes:

> Hi Peter,
>
> On 26 October 2013 at 21:34, Peter Caspers wrote:
> |    is it possible to build the SWIG R package with -std=c++11 ? As far
> | as I can see during the execution of R CMD check R one step
> | 
> | * checking whether package ‘QuantLib’ can be installed ... ERROR
> | 
> | fails because some hard coded (?) configuration (not related to the one
> | produced with the usual ./configure ... call) is used here, in the log
> | R.Rcheck/00install.out I get
> | 
> | make[3]: Entering directory `/home/peter/quantlibpc/QuantLib-SWIG/R/src'
> | g++ -I/usr/share/R/include -DNDEBUG `quantlib-config --cflags`      -fpic  -O3 -pipe  -g  -c QuantLib.cpp -o QuantLib.o
> | 
> | which fails because of some c++11 elements in my client quantlib code.
>
> Interesting question. The whole 'R and C++11' nexus is a little toxic (as the
> CRAN gatekeepers exists on the older standard; some of us are working behind
> the scenes to change that).  By and large, using -std=c++11 should not bite.
> We use it for a things with Rcpp,  but because we cannot (yet!!) upload to
> CRAN with it, there isn't as much testing for C++11.  
>
> R itself is in C and does not care. Boost may care (and Boost 2.0 will be
> guaranteed to work this way). No idea about Swig. I haven't built the QL-Swig
> bindings in a while.
>
> Now, your post doesn't actually show the error. What happens when you simply
> set appropriate CXXFLAGS as in 
>
>     CXXFLAGS= -g -O3 -Wall -pipe -Wno-unused -pedantic -std=c++11
>
> (I usually do that in ~/.R/Makevars; you can also set it per package in
> src/Makevars).
>
> Can you try and report back?
>
> Dirk

Re: [Quantlib-dev] SWIG R with c++11

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

Hi Peter,

On 26 October 2013 at 21:34, Peter Caspers wrote:
|    is it possible to build the SWIG R package with -std=c++11 ? As far
| as I can see during the execution of R CMD check R one step
| 
| * checking whether package ‘QuantLib’ can be installed ... ERROR
| 
| fails because some hard coded (?) configuration (not related to the one
| produced with the usual ./configure ... call) is used here, in the log
| R.Rcheck/00install.out I get
| 
| make[3]: Entering directory `/home/peter/quantlibpc/QuantLib-SWIG/R/src'
| g++ -I/usr/share/R/include -DNDEBUG `quantlib-config --cflags`      -fpic  -O3 -pipe  -g  -c QuantLib.cpp -o QuantLib.o
| 
| which fails because of some c++11 elements in my client quantlib code.

Interesting question. The whole 'R and C++11' nexus is a little toxic (as the
CRAN gatekeepers exists on the older standard; some of us are working behind
the scenes to change that).  By and large, using -std=c++11 should not bite.
We use it for a things with Rcpp,  but because we cannot (yet!!) upload to
CRAN with it, there isn't as much testing for C++11.  

R itself is in C and does not care. Boost may care (and Boost 2.0 will be
guaranteed to work this way). No idea about Swig. I haven't built the QL-Swig
bindings in a while.

Now, your post doesn't actually show the error. What happens when you simply
set appropriate CXXFLAGS as in 

    CXXFLAGS= -g -O3 -Wall -pipe -Wno-unused -pedantic -std=c++11

(I usually do that in ~/.R/Makevars; you can also set it per package in
src/Makevars).

Can you try and report back?

Dirk

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

[Quantlib-dev] SWIG R with c++11

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

Hi,

   is it possible to build the SWIG R package with -std=c++11 ? As far
as I can see during the execution of R CMD check R one step

* checking whether package ‘QuantLib’ can be installed ... ERROR

fails because some hard coded (?) configuration (not related to the one
produced with the usual ./configure ... call) is used here, in the log
R.Rcheck/00install.out I get

make[3]: Entering directory `/home/peter/quantlibpc/QuantLib-SWIG/R/src'
g++ -I/usr/share/R/include -DNDEBUG `quantlib-config --cflags`      -fpic  -O3 -pipe  -g  -c QuantLib.cpp -o QuantLib.o

which fails because of some c++11 elements in my client quantlib code.

Thanks a lot 
    Peter

Re: [Quantlib-dev] selective model calibration

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

Here is what I'd suggest.

https://github.com/lballabio/quantlib/pull/48

Everything should be backward compatible except for a different default
behaviour of the markov model, which gives a better fit to the secondary
calibration instruments now, see below.

>From the end user perspective it is e.g. possible to write

model->calibrate(swaptions, optimizationMethod, endCriteria,
                 Constraint(), std::vector<Real>(),
                 HullWhite::CalibrationConstraints::FixedReversion());

and only calibrate the volatility while kepping the reversion fixed on
its initial value.

The second application is for the markov model where I added a constraint
FixedFirstVolatility(), which I also made the default constraint by
overwriting the calibrate function in the markov class itself. One
should set a volatility step date on each secondary calibration
instrument expiry (different from a piecewise Hull White model for
example where you usually leave out the last expiry). The first
volatility only gives the scaling of the volatility vector and can be
set to 0.01. See the updated test case for an example.

It should be easy to add similar constraints to other models.

Note that I follow the convention in ProjectedCostFunction where true
means that a parameter is fixed and false that it is free (which
confused me a bit).

A little complication was that we do not only need a projected cost
function, but also a projected constraint. Therefore I abstracted out
the projection part which is now used by both ProjectedCostFunction and
ProjectedConstraint. The CalibrationFunction directly uses Projection
and not the projected cost function. I tried the latter first but it
produced code that looked slightly strange.

I added a test case for the HullWhite example and amended the markov
test case.

It would be great if you could have a look and try to adapt your own
model code to the new design and see if it works for you too.

Thanks a lot, see you
    Peter


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

> Yes, it sounds interesting.  I would add the extra vector parameter to
> calculate();
> derived classes might provide functions that return predetermined vectors, e.g.,
>
> model->calibrate(helpers, ...,  HullWhite::constraints::keep_reversion_fixed())
>
> or
>
> model->calibrate(helpers, ...,
> HullWhite::constraints::move_single_volatility(i));
>
> or something shorter, of course :)
>
> This way, derived classes wouldn't even have to override calibrate().
>
> Later,
>     Luigi
>
>
>
> On Thu, Oct 24, 2013 at 10:36 AM, Roland Lichters
> <rol...@go...> wrote:
>> Hi Peter,
>>
>> that sounds interesting and useful. I keep coming across your first
>> case, and I solved it so far by passing a vector of booleans to the
>> model constructor and setting up calibration params and indices to
>> them accordingly, in each model constructor, without changing
>> QuantLib. It is not elegant, but one can select which part of the
>> parameters are calibrated and avoid dealing with various copies of
>> the model. I'd be curious to see whether this can be achieved with
>> less coding when we change QuantLib as you suggest. Your second case
>> didn't even occur to me yet.
>> Can we have a look at a code example? I am also happy to share my pedestrian approach if of interest.
>>
>> Regards,
>> Roland
>>
>>
>> On 23 Oct 2013, at 21:37, Peter Caspers <pca...@gm...> wrote:
>>
>>> Hi,
>>>
>>>  I would like to be able to calibrate only a subset of the parameters
>>> of a CalibratedModel instance. Even more I would like to fix a subset of
>>> elements within one multidimensional parameter in some cases. With this
>>> one could e.g.
>>>
>>> - calibrate both reversion and volatilities or fix the reversion and
>>> calibrate only volatilities in a Hull White model
>>>
>>> - calibrate the model volatilities in a Hull White model iteratively to
>>> single interest rate options with ascending option maturities instead
>>> of having to do a global calibration to the whole set (which can be
>>> much slower when you have many options in the calibration basket)
>>>
>>> - easily avoid the redundancy in the piecewise volatlities of a markov
>>> model (multiplying the volatilies by a (non zero) scalar factor does
>>> not change the model up to numeraire recalibration)
>>>
>>> There are probably more use cases. I guess there are workarounds for
>>> most of these cases, but I would like to propose a solution in the
>>> CalibratedModel class itself. Since I am not sure about the design I am
>>> not just sending a pull request but would like to discuss the approach
>>> first. Here is what I would try:
>>>
>>> Add a parameter to the calibrate method specifying the free parameters
>>> in a vector<bool> and defaulting to an empty vector meaning all
>>> parameters are free. Within the method one can make use of the
>>> ProjectedCostFunction then to easily get what we want. One could also
>>> make this calibrate method protected and leave the public interface as
>>> it is, just invoking the new method with the default for the new
>>> parameter. That is probably better because on the level of the
>>> CalibratedModel one does not know the meaning of the parameters and
>>> of their components.
>>>
>>> Again in the protected section, provide an inner class that allows to
>>> construct the above vector<bool> conveniently from specifying parameters
>>> to include or exclude or indices within a parameter to include or
>>> exclude in or from the set of free parameters.
>>>
>>> This does not change anything so far. However derived models can now
>>> easily overwrite the calibrate method (which we would have to make
>>> virtual) and do a specialized calibration as needed / specified in the
>>> concrete models.
>>>
>>> What do you think ?
>>>
>>> regards
>>>  Peter
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] selective model calibration

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

this is even better !
thanks a lot
    Peter


On 24 October 2013 11:30, Luigi Ballabio <lui...@gm...> wrote:

> Yes, it sounds interesting.  I would add the extra vector parameter to
> calculate();
> derived classes might provide functions that return predetermined vectors,
> e.g.,
>
> model->calibrate(helpers, ...,
>  HullWhite::constraints::keep_reversion_fixed())
>
> or
>
> model->calibrate(helpers, ...,
> HullWhite::constraints::move_single_volatility(i));
>
> or something shorter, of course :)
>
> This way, derived classes wouldn't even have to override calibrate().
>
> Later,
>     Luigi
>
>
>
> On Thu, Oct 24, 2013 at 10:36 AM, Roland Lichters
> <rol...@go...> wrote:
> > Hi Peter,
> >
> > that sounds interesting and useful. I keep coming across your first
> case, and I solved it so far by passing a vector of booleans to the model
> constructor and setting up calibration params and indices to them
> accordingly, in each model constructor, without changing QuantLib. It is
> not elegant, but one can select which part of the parameters are calibrated
> and avoid dealing with various copies of the model. I'd be curious to see
> whether this can be achieved with less coding when we change QuantLib as
> you suggest. Your second case didn't even occur to me yet.
> > Can we have a look at a code example? I am also happy to share my
> pedestrian approach if of interest.
> >
> > Regards,
> > Roland
> >
> >
> > On 23 Oct 2013, at 21:37, Peter Caspers <pca...@gm...> wrote:
> >
> >> Hi,
> >>
> >>  I would like to be able to calibrate only a subset of the parameters
> >> of a CalibratedModel instance. Even more I would like to fix a subset of
> >> elements within one multidimensional parameter in some cases. With this
> >> one could e.g.
> >>
> >> - calibrate both reversion and volatilities or fix the reversion and
> >> calibrate only volatilities in a Hull White model
> >>
> >> - calibrate the model volatilities in a Hull White model iteratively to
> >> single interest rate options with ascending option maturities instead
> >> of having to do a global calibration to the whole set (which can be
> >> much slower when you have many options in the calibration basket)
> >>
> >> - easily avoid the redundancy in the piecewise volatlities of a markov
> >> model (multiplying the volatilies by a (non zero) scalar factor does
> >> not change the model up to numeraire recalibration)
> >>
> >> There are probably more use cases. I guess there are workarounds for
> >> most of these cases, but I would like to propose a solution in the
> >> CalibratedModel class itself. Since I am not sure about the design I am
> >> not just sending a pull request but would like to discuss the approach
> >> first. Here is what I would try:
> >>
> >> Add a parameter to the calibrate method specifying the free parameters
> >> in a vector<bool> and defaulting to an empty vector meaning all
> >> parameters are free. Within the method one can make use of the
> >> ProjectedCostFunction then to easily get what we want. One could also
> >> make this calibrate method protected and leave the public interface as
> >> it is, just invoking the new method with the default for the new
> >> parameter. That is probably better because on the level of the
> >> CalibratedModel one does not know the meaning of the parameters and
> >> of their components.
> >>
> >> Again in the protected section, provide an inner class that allows to
> >> construct the above vector<bool> conveniently from specifying parameters
> >> to include or exclude or indices within a parameter to include or
> >> exclude in or from the set of free parameters.
> >>
> >> This does not change anything so far. However derived models can now
> >> easily overwrite the calibrate method (which we would have to make
> >> virtual) and do a specialized calibration as needed / specified in the
> >> concrete models.
> >>
> >> What do you think ?
> >>
> >> regards
> >>  Peter
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> October Webinars: Code for Performance
> >> Free Intel webinars can help you accelerate application performance.
> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> >> the latest Intel processors and coprocessors. See abstracts and
> register >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> QuantLib-dev mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>

Re: [Quantlib-dev] selective model calibration

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

Yes, it sounds interesting.  I would add the extra vector parameter to
calculate();
derived classes might provide functions that return predetermined vectors, e.g.,

model->calibrate(helpers, ...,  HullWhite::constraints::keep_reversion_fixed())

or

model->calibrate(helpers, ...,
HullWhite::constraints::move_single_volatility(i));

or something shorter, of course :)

This way, derived classes wouldn't even have to override calibrate().

Later,
    Luigi



On Thu, Oct 24, 2013 at 10:36 AM, Roland Lichters
<rol...@go...> wrote:
> Hi Peter,
>
> that sounds interesting and useful. I keep coming across your first case, and I solved it so far by passing a vector of booleans to the model constructor and setting up calibration params and indices to them accordingly, in each model constructor, without changing QuantLib. It is not elegant, but one can select which part of the parameters are calibrated and avoid dealing with various copies of the model. I'd be curious to see whether this can be achieved with less coding when we change QuantLib as you suggest. Your second case didn't even occur to me yet.
> Can we have a look at a code example? I am also happy to share my pedestrian approach if of interest.
>
> Regards,
> Roland
>
>
> On 23 Oct 2013, at 21:37, Peter Caspers <pca...@gm...> wrote:
>
>> Hi,
>>
>>  I would like to be able to calibrate only a subset of the parameters
>> of a CalibratedModel instance. Even more I would like to fix a subset of
>> elements within one multidimensional parameter in some cases. With this
>> one could e.g.
>>
>> - calibrate both reversion and volatilities or fix the reversion and
>> calibrate only volatilities in a Hull White model
>>
>> - calibrate the model volatilities in a Hull White model iteratively to
>> single interest rate options with ascending option maturities instead
>> of having to do a global calibration to the whole set (which can be
>> much slower when you have many options in the calibration basket)
>>
>> - easily avoid the redundancy in the piecewise volatlities of a markov
>> model (multiplying the volatilies by a (non zero) scalar factor does
>> not change the model up to numeraire recalibration)
>>
>> There are probably more use cases. I guess there are workarounds for
>> most of these cases, but I would like to propose a solution in the
>> CalibratedModel class itself. Since I am not sure about the design I am
>> not just sending a pull request but would like to discuss the approach
>> first. Here is what I would try:
>>
>> Add a parameter to the calibrate method specifying the free parameters
>> in a vector<bool> and defaulting to an empty vector meaning all
>> parameters are free. Within the method one can make use of the
>> ProjectedCostFunction then to easily get what we want. One could also
>> make this calibrate method protected and leave the public interface as
>> it is, just invoking the new method with the default for the new
>> parameter. That is probably better because on the level of the
>> CalibratedModel one does not know the meaning of the parameters and
>> of their components.
>>
>> Again in the protected section, provide an inner class that allows to
>> construct the above vector<bool> conveniently from specifying parameters
>> to include or exclude or indices within a parameter to include or
>> exclude in or from the set of free parameters.
>>
>> This does not change anything so far. However derived models can now
>> easily overwrite the calibrate method (which we would have to make
>> virtual) and do a specialized calibration as needed / specified in the
>> concrete models.
>>
>> What do you think ?
>>
>> regards
>>  Peter
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] selective model calibration

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

Hi Roland,

actually the third case is my core motivation since it seems not really
possible to keep only the first component of a piecewise parameter fixed
during calibration. A workaround is possible also in this case, but it is
really ugly.

Concerning the second case I observed that calibrating a Hull White Model
with piecewise volatility to 1y/34y, 2y/33y, ... 34y/1y at the money
coterminal swaptions (the reversion being fixed) takes significantly longer
using a 34-dim Levenberg-Marquardt optimzation compared to 34 1-dim
optimzations or zero searches. I can send example code, however it relies
on a not yet officially released implementation of a GSR model (as
described by Piterbarg). Up to now I added a "calibrateIterative(...)" -
method to CalibratedModel as a workaround, but you have to consider in
which situations this will work correctly before applying it. It would be
much nicer to have a robust implementation in the GSR model itself, where
you can take care of executing the procedure correctly just by invoking the
base class method for each option and fix the respective components in each
iteration.

Do you still think example code for the second case would be useful (then I
will prepare something you can pull) or can you run a test like the one
above easily on your side as well ?

I think the general solution will not require much coding, so I will give
it a try on the weekend.

regards
    Peter



On 24 October 2013 10:36, Roland Lichters <rol...@go...>wrote:

> Hi Peter,
>
> that sounds interesting and useful. I keep coming across your first case,
> and I solved it so far by passing a vector of booleans to the model
> constructor and setting up calibration params and indices to them
> accordingly, in each model constructor, without changing QuantLib. It is
> not elegant, but one can select which part of the parameters are calibrated
> and avoid dealing with various copies of the model. I'd be curious to see
> whether this can be achieved with less coding when we change QuantLib as
> you suggest. Your second case didn't even occur to me yet.
> Can we have a look at a code example? I am also happy to share my
> pedestrian approach if of interest.
>
> Regards,
> Roland
>
>
> On 23 Oct 2013, at 21:37, Peter Caspers <pca...@gm...> wrote:
>
> > Hi,
> >
> >  I would like to be able to calibrate only a subset of the parameters
> > of a CalibratedModel instance. Even more I would like to fix a subset of
> > elements within one multidimensional parameter in some cases. With this
> > one could e.g.
> >
> > - calibrate both reversion and volatilities or fix the reversion and
> > calibrate only volatilities in a Hull White model
> >
> > - calibrate the model volatilities in a Hull White model iteratively to
> > single interest rate options with ascending option maturities instead
> > of having to do a global calibration to the whole set (which can be
> > much slower when you have many options in the calibration basket)
> >
> > - easily avoid the redundancy in the piecewise volatlities of a markov
> > model (multiplying the volatilies by a (non zero) scalar factor does
> > not change the model up to numeraire recalibration)
> >
> > There are probably more use cases. I guess there are workarounds for
> > most of these cases, but I would like to propose a solution in the
> > CalibratedModel class itself. Since I am not sure about the design I am
> > not just sending a pull request but would like to discuss the approach
> > first. Here is what I would try:
> >
> > Add a parameter to the calibrate method specifying the free parameters
> > in a vector<bool> and defaulting to an empty vector meaning all
> > parameters are free. Within the method one can make use of the
> > ProjectedCostFunction then to easily get what we want. One could also
> > make this calibrate method protected and leave the public interface as
> > it is, just invoking the new method with the default for the new
> > parameter. That is probably better because on the level of the
> > CalibratedModel one does not know the meaning of the parameters and
> > of their components.
> >
> > Again in the protected section, provide an inner class that allows to
> > construct the above vector<bool> conveniently from specifying parameters
> > to include or exclude or indices within a parameter to include or
> > exclude in or from the set of free parameters.
> >
> > This does not change anything so far. However derived models can now
> > easily overwrite the calibrate method (which we would have to make
> > virtual) and do a specialized calibration as needed / specified in the
> > concrete models.
> >
> > What do you think ?
> >
> > regards
> >  Peter
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null

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

Ok, I see.  It's YieldTermStructure::update(), which gets called when
the zero-spreaded curve is notified that the discount handle has
changed and tries to calculate the new reference date. Except it
can't, because the handle is empty.

As a quick and dirty fix, wrap the "if" in
YieldTermStructure::update() in a try/catch and just block the
exception. But be aware that this could hide other problems, i.e.,
actual exceptions in setJumps(). I'll try and commit a more robust
patch in the repository.

Luigi


On Wed, Oct 23, 2013 at 11:13 PM, Breig, Dr. Christoph (IDS GmbH)
<CHR...@in...> wrote:
> Hi Luigi, hi all,
> yes, here is it. Do you have an idea how to reset "discTermStructure" after the initialisation of "spreadedDiscTermStructure".
> -------------------
> #include <ql/quantlib.hpp>
>
> using namespace QuantLib;
>
> int main(int, char* []) {
>
>     try {
>
>                 QuantLib::RelinkableHandle<QuantLib::YieldTermStructure> discTermStructure;
>                 boost::shared_ptr<YieldTermStructure> nullYTSPtr;
>                 Date evaluationDate = Date(23,Month(10),2013);
>                 boost::shared_ptr<YieldTermStructure> yts(new FlatForward(evaluationDate, 0.02, ActualActual()));
>                 discTermStructure.linkTo(yts);
>                 boost::shared_ptr<Quote> spread(new SimpleQuote(0.02));
>
>                 // no problem
>                 discTermStructure.linkTo(nullYTSPtr);
>                 discTermStructure.linkTo(yts);
>
>                 // problem
>                 boost::shared_ptr<YieldTermStructure> spreadedDiscTermStructure(new ZeroSpreadedTermStructure(discTermStructure,Handle<Quote>(spread)));
>                 discTermStructure.linkTo(nullYTSPtr);
>
>                 system("PAUSE");
>         return 0;
>
>     } catch (std::exception& e) {
>         std::cerr << e.what() << std::endl;
>                 system("PAUSE");
>         return 1;
>     } catch (...) {
>         std::cerr << "unknown error" << std::endl;
>                 system("PAUSE");
>         return 1;
>     }
> }
>
> -------------
>
> Best and thx
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: Luigi Ballabio [mailto:lui...@gm...]
> Gesendet: Mittwoch, 23. Oktober 2013 18:08
> An: Breig, Dr. Christoph (IDS GmbH)
> Cc: QuantLib developers
> Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null
>
> It looks like the spreaded curve notifies its observers of the change,
> one of them tries to perform some calculation as a consequence, and
> the calculation fails because the handle is empty.  Can you reproduce
> the problem in a short program you can post?
>
> Luigi
>
>
> On Wed, Oct 23, 2013 at 4:49 PM, Breig, Dr. Christoph (IDS GmbH)
> <CHR...@in...> wrote:
>> Hi Luigi, hi all
>>
>> the empty shared_ptr works fine for e.g. InterpolatedZeroCurves but not for
>> ZeroSpreadedTermStructures. Then, while setting the empty shared_ptr,
>> following error messages takes place:
>> "could not notify one or more observers: empty Handle cannot be
>> dereferenced"
>>
>> I'm at the moment using version 1.0 of QuantLib (in case the problem is a
>> bug and was already fixed).
>>
>> Best and thanks
>> Chris
>>
>> ________________________________
>> Von: Luigi Ballabio [mailto:lui...@gm...]
>> Gesendet: Freitag, 18. Oktober 2013 16:13
>> An: Breig, Dr. Christoph (IDS GmbH)
>> Cc: QuantLib developers
>> Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to
>> Null
>>
>> Hi,
>>     link it to an empty shared_ptr.
>>
>> Luigi
>>
>> On Oct 18, 2013 4:01 PM, "Breig, Dr. Christoph (IDS GmbH)"
>> <CHR...@in...> wrote:
>>>
>>> Dear all,
>>>
>>> has anybody an idea how to set a Relinkable Handle who is already linked
>>> to a YieldTermStructure object back to Null, so that the function
>>> "empty()" returns again true?
>>>
>>> Best and thanks
>>> Chris
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] selective model calibration

[Roland L. <rol...@go...>]

Hi Peter,

that sounds interesting and useful. I keep coming across your first case, and I solved it so far by passing a vector of booleans to the model constructor and setting up calibration params and indices to them accordingly, in each model constructor, without changing QuantLib. It is not elegant, but one can select which part of the parameters are calibrated and avoid dealing with various copies of the model. I'd be curious to see whether this can be achieved with less coding when we change QuantLib as you suggest. Your second case didn't even occur to me yet. 
Can we have a look at a code example? I am also happy to share my pedestrian approach if of interest.

Regards,
Roland 


On 23 Oct 2013, at 21:37, Peter Caspers <pca...@gm...> wrote:

> Hi,
> 
>  I would like to be able to calibrate only a subset of the parameters
> of a CalibratedModel instance. Even more I would like to fix a subset of
> elements within one multidimensional parameter in some cases. With this
> one could e.g.
> 
> - calibrate both reversion and volatilities or fix the reversion and
> calibrate only volatilities in a Hull White model
> 
> - calibrate the model volatilities in a Hull White model iteratively to
> single interest rate options with ascending option maturities instead
> of having to do a global calibration to the whole set (which can be
> much slower when you have many options in the calibration basket)
> 
> - easily avoid the redundancy in the piecewise volatlities of a markov
> model (multiplying the volatilies by a (non zero) scalar factor does
> not change the model up to numeraire recalibration)
> 
> There are probably more use cases. I guess there are workarounds for
> most of these cases, but I would like to propose a solution in the
> CalibratedModel class itself. Since I am not sure about the design I am
> not just sending a pull request but would like to discuss the approach
> first. Here is what I would try:
> 
> Add a parameter to the calibrate method specifying the free parameters
> in a vector<bool> and defaulting to an empty vector meaning all
> parameters are free. Within the method one can make use of the
> ProjectedCostFunction then to easily get what we want. One could also
> make this calibrate method protected and leave the public interface as
> it is, just invoking the new method with the default for the new
> parameter. That is probably better because on the level of the
> CalibratedModel one does not know the meaning of the parameters and
> of their components.
> 
> Again in the protected section, provide an inner class that allows to
> construct the above vector<bool> conveniently from specifying parameters
> to include or exclude or indices within a parameter to include or
> exclude in or from the set of free parameters.
> 
> This does not change anything so far. However derived models can now
> easily overwrite the calibrate method (which we would have to make
> virtual) and do a specialized calibration as needed / specified in the
> concrete models.
> 
> What do you think ?
> 
> regards
>  Peter
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null

[Breig, D. C. (I. GmbH) <CHR...@IN...>]

Hi Luigi, hi all,
yes, here is it. Do you have an idea how to reset "discTermStructure" after the initialisation of "spreadedDiscTermStructure".
-------------------
#include <ql/quantlib.hpp>

using namespace QuantLib;

int main(int, char* []) {

    try {
		
		QuantLib::RelinkableHandle<QuantLib::YieldTermStructure> discTermStructure;
		boost::shared_ptr<YieldTermStructure> nullYTSPtr;
		Date evaluationDate = Date(23,Month(10),2013);
		boost::shared_ptr<YieldTermStructure> yts(new FlatForward(evaluationDate, 0.02, ActualActual()));
		discTermStructure.linkTo(yts);
		boost::shared_ptr<Quote> spread(new SimpleQuote(0.02));

		// no problem
		discTermStructure.linkTo(nullYTSPtr);
		discTermStructure.linkTo(yts);

		// problem
		boost::shared_ptr<YieldTermStructure> spreadedDiscTermStructure(new ZeroSpreadedTermStructure(discTermStructure,Handle<Quote>(spread)));
		discTermStructure.linkTo(nullYTSPtr);
		
		system("PAUSE");
        return 0;

    } catch (std::exception& e) {
        std::cerr << e.what() << std::endl;
		system("PAUSE");
        return 1;
    } catch (...) {
        std::cerr << "unknown error" << std::endl;
		system("PAUSE");
        return 1;
    }
}

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

Best and thx
Chris

-----Ursprüngliche Nachricht-----
Von: Luigi Ballabio [mailto:lui...@gm...] 
Gesendet: Mittwoch, 23. Oktober 2013 18:08
An: Breig, Dr. Christoph (IDS GmbH)
Cc: QuantLib developers
Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null

It looks like the spreaded curve notifies its observers of the change,
one of them tries to perform some calculation as a consequence, and
the calculation fails because the handle is empty.  Can you reproduce
the problem in a short program you can post?

Luigi


On Wed, Oct 23, 2013 at 4:49 PM, Breig, Dr. Christoph (IDS GmbH)
<CHR...@in...> wrote:
> Hi Luigi, hi all
>
> the empty shared_ptr works fine for e.g. InterpolatedZeroCurves but not for
> ZeroSpreadedTermStructures. Then, while setting the empty shared_ptr,
> following error messages takes place:
> "could not notify one or more observers: empty Handle cannot be
> dereferenced"
>
> I'm at the moment using version 1.0 of QuantLib (in case the problem is a
> bug and was already fixed).
>
> Best and thanks
> Chris
>
> ________________________________
> Von: Luigi Ballabio [mailto:lui...@gm...]
> Gesendet: Freitag, 18. Oktober 2013 16:13
> An: Breig, Dr. Christoph (IDS GmbH)
> Cc: QuantLib developers
> Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to
> Null
>
> Hi,
>     link it to an empty shared_ptr.
>
> Luigi
>
> On Oct 18, 2013 4:01 PM, "Breig, Dr. Christoph (IDS GmbH)"
> <CHR...@in...> wrote:
>>
>> Dear all,
>>
>> has anybody an idea how to set a Relinkable Handle who is already linked
>> to a YieldTermStructure object back to Null, so that the function
>> "empty()" returns again true?
>>
>> Best and thanks
>> Chris
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

[Quantlib-dev] selective model calibration

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

Hi,

   I would like to be able to calibrate only a subset of the parameters
of a CalibratedModel instance. Even more I would like to fix a subset of
elements within one multidimensional parameter in some cases. With this
one could e.g.

- calibrate both reversion and volatilities or fix the reversion and
  calibrate only volatilities in a Hull White model

- calibrate the model volatilities in a Hull White model iteratively to
  single interest rate options with ascending option maturities instead
  of having to do a global calibration to the whole set (which can be
  much slower when you have many options in the calibration basket)

- easily avoid the redundancy in the piecewise volatlities of a markov
  model (multiplying the volatilies by a (non zero) scalar factor does
  not change the model up to numeraire recalibration)

There are probably more use cases. I guess there are workarounds for
most of these cases, but I would like to propose a solution in the
CalibratedModel class itself. Since I am not sure about the design I am
not just sending a pull request but would like to discuss the approach
first. Here is what I would try:

Add a parameter to the calibrate method specifying the free parameters
in a vector<bool> and defaulting to an empty vector meaning all
parameters are free. Within the method one can make use of the
ProjectedCostFunction then to easily get what we want. One could also
make this calibrate method protected and leave the public interface as
it is, just invoking the new method with the default for the new
parameter. That is probably better because on the level of the
CalibratedModel one does not know the meaning of the parameters and
of their components.

Again in the protected section, provide an inner class that allows to
construct the above vector<bool> conveniently from specifying parameters
to include or exclude or indices within a parameter to include or
exclude in or from the set of free parameters.

This does not change anything so far. However derived models can now
easily overwrite the calibrate method (which we would have to make
virtual) and do a specialized calibration as needed / specified in the
concrete models.

What do you think ?

regards
   Peter


 

Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null

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

It looks like the spreaded curve notifies its observers of the change,
one of them tries to perform some calculation as a consequence, and
the calculation fails because the handle is empty.  Can you reproduce
the problem in a short program you can post?

Luigi


On Wed, Oct 23, 2013 at 4:49 PM, Breig, Dr. Christoph (IDS GmbH)
<CHR...@in...> wrote:
> Hi Luigi, hi all
>
> the empty shared_ptr works fine for e.g. InterpolatedZeroCurves but not for
> ZeroSpreadedTermStructures. Then, while setting the empty shared_ptr,
> following error messages takes place:
> "could not notify one or more observers: empty Handle cannot be
> dereferenced"
>
> I'm at the moment using version 1.0 of QuantLib (in case the problem is a
> bug and was already fixed).
>
> Best and thanks
> Chris
>
> ________________________________
> Von: Luigi Ballabio [mailto:lui...@gm...]
> Gesendet: Freitag, 18. Oktober 2013 16:13
> An: Breig, Dr. Christoph (IDS GmbH)
> Cc: QuantLib developers
> Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to
> Null
>
> Hi,
>     link it to an empty shared_ptr.
>
> Luigi
>
> On Oct 18, 2013 4:01 PM, "Breig, Dr. Christoph (IDS GmbH)"
> <CHR...@in...> wrote:
>>
>> Dear all,
>>
>> has anybody an idea how to set a Relinkable Handle who is already linked
>> to a YieldTermStructure object back to Null, so that the function
>> "empty()" returns again true?
>>
>> Best and thanks
>> Chris
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null

[Breig, D. C. (I. GmbH) <CHR...@IN...>]

Hi Luigi, hi all

the empty shared_ptr works fine for e.g. InterpolatedZeroCurves but not for ZeroSpreadedTermStructures. Then, while setting the empty shared_ptr, following error messages takes place:
"could not notify one or more observers: empty Handle cannot be dereferenced"

I'm at the moment using version 1.0 of QuantLib (in case the problem is a bug and was already fixed).

Best and thanks
Chris

________________________________
Von: Luigi Ballabio [mailto:lui...@gm...]
Gesendet: Freitag, 18. Oktober 2013 16:13
An: Breig, Dr. Christoph (IDS GmbH)
Cc: QuantLib developers
Betreff: Re: [Quantlib-dev] RelinkableHandle<YieldTermStructure> reset to Null


Hi,
    link it to an empty shared_ptr.

Luigi

On Oct 18, 2013 4:01 PM, "Breig, Dr. Christoph (IDS GmbH)" <CHR...@in...<mailto:CHR...@in...>> wrote:
Dear all,

has anybody an idea how to set a Relinkable Handle who is already linked to a YieldTermStructure object back to Null, so that the function
"empty()" returns again true?

Best and thanks
Chris

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Openmp work on mcarlo

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

It sounds like a plan.  I'll have to look into defaulting openmp to
off (the macro defaults to on). Also, I'm adding a few comments to
your pull request.  Once the initial mods are in, I would go for a
long-lived branch in your fork (so that you remain in charge of
managing related pull requests). Backward compatibility would be
great, assuming that it doesn't make the code brittle, but I'm afraid
the time you'd have to put into that could be better spent...

Later,
    Luigi



On Tue, Oct 22, 2013 at 2:21 PM, Joseph Wang <joe...@gm...> wrote:
> Can we move onto the main tree any changes that don't break backward
> compatibility and then leave anything that does break compatibility on the
> outside until we figure out what the best way of handling things are?
>
> If we default openmp to off, then the changes to lattice and fd give some
> speedups without breaking compatbility.  We can then work on the things that
> break compatibility separately.  Parallelzing mcarlo turns out to be
> extremely tricky so I want to work on it separately.  In particular, I want
> to make absolutely sure that there is no way we can still maintain backward
> compatibility.
>
> When I worked on a similar problem on a different code base, we managed to
> preserve backward compatibility, but is was a really, really hard slog
> involving a lot of very delicate coding.  If I can play with the code for a
> while, it might be possible to do the same thing.
>
>
>
> On Tue, Oct 22, 2013 at 6:13 PM, Luigi Ballabio <lui...@gm...>
> wrote:
>>
>> Hi Joseph,
>>     it will probably be a while before we add to the main branch any
>> changes that break backward compatibility.  How about I create a
>> long-lived branch for your changes and I pull your changes there? The
>> advantage would be that your code might be found more easily. On the
>> other hand, the disadvantage is that pull requests from other people
>> might get made against my repo, not yours, even though the right
>> person to manage them would be you instead; this would be easier if
>> your fork was the reference for further development.
>>
>> Just let me know what you prefer.
>>
>> Later,
>>     Luigi
>>
>>
>>
>> On Tue, Oct 22, 2013 at 4:51 AM, Joseph Wang <joe...@gm...> wrote:
>> > It's possible to figure out the number of random number evaluations, and
>> > then skip ahead N evaluations for each thread.  In practice this works
>> > but
>> > the code is very fragile.  Having each thread have its own state is also
>> > used but it requires the user to know ahead of time how many threads to
>> > use,
>> > and you have to be very careful not to introduce bad correlations.
>> >
>> > I'm trying to get deterministic order by putting the RNG into a critical
>> > section.  Right now the goal isn't to get the same order between non-OMP
>> > and
>> > OMP but to at least get identical answers between different OMP runs.
>> > This
>> > isn't a hard algorithm issue, but its a C++ class/architecture issue,
>> > since
>> > it involves changing the interface of the MC classes, and I'd like to
>> > get
>> > this right before moving anything to the main code branch.
>> >
>> > One other technique that I've see is to generate all of the paths ahead
>> > of
>> > time, store in memory and the run the pricing afterwards.  This gets you
>> > deterministic ordering, and you can do clever things with RNG, and it's
>> > very
>> > useful for generating greeks, but you then have to carefully manage
>> > memory,
>> > and I want to avoid that.
>> >
>> > I've been able to get nice speedups with OpenMP with FD and lattice, and
>> > I'd
>> > appreciate it if people could test the patches (openmp branch on
>> > joequant/quantlib github).  One thing that MP does is favor simple
>> > schemes
>> > so I've parallelized those.  There are some well known MP algorithms for
>> > tridiagonalizing a matrix and I can implement that once MC gets put in.
>> >
>> >
>> >
>> > On Tue, Oct 22, 2013 at 4:31 AM, Kyle Schlansker <ky...@th...>
>> > wrote:
>> >>
>> >> I think the standard solution is to have each thread maintain its own
>> >> state (i.e. rand seed).
>> >>
>> >> Having a shared q, lock free or not, would then introduce
>> >> nondeterminism
>> >> unless all consumer threads read from that q in the same order from run
>> >> to
>> >> run, which it seems is not guaranteed.
>> >>
>> >> --
>> >> kyle
>> >>
>> >> Sent from my mobile; apologies for any deficiencies of spelling or
>> >> message
>> >> tone.
>> >>
>> >> On Oct 21, 2013, at 2:53 PM, Mike Sharpe <ma...@gm...> wrote:
>> >>
>> >> Does the number of random numbers needed per iteration change or is it
>> >> a
>> >> constant amount?
>> >>
>> >> Would it be possible to encapsulate the random generator state so each
>> >> thread could own its own RNG?
>> >>
>> >> If that isn't feasible or reduces the quality of the generation, would
>> >> it
>> >> be possible to spawn a producer thread that pushes random numbers onto
>> >> a
>> >> queue (could even investigate boost::lockfree::queue to avoid locking,
>> >> though it requires boost 1.53) and have the worker thread just pop off
>> >> from
>> >> that queue whenever a new random number is needed?
>> >>
>> >> Mike
>> >>
>> >>
>> >> On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...>
>> >> wrote:
>> >>>
>> >>> I've done some more parallelization with openmp and quantlib.  I've
>> >>> uploaded the changes to the https://github.com/joequant/quantlib.  The
>> >>> branch openmp has some changes that I've issued a pull-request for.
>> >>> openmp-mcario has some changes that need some more work.
>> >>>
>> >>> I've gotten the MC to work by generating the paths in a critical
>> >>> situation.  Calculating the prices once I have the path is
>> >>> multithreaded,
>> >>> but right now I need to generate the paths in a single thread to make
>> >>> sure
>> >>> that the same sequence is generated.
>> >>>
>> >>> The big issue right now is that there is a race condition in the
>> >>> calculation of barrier options which is causing one regression test to
>> >>> fail.
>> >>> The problem is that the random number generator is being called in
>> >>> BarrierPathPricer, and since that is run multithread, the sequence
>> >>> that is
>> >>> being pulled will change from run to run based on whether other paths
>> >>> have
>> >>> pulled random numbers already.
>> >>>
>> >>> I think that fixing this is going to need some code restructuring, but
>> >>> I'd like to get some thoughts as to how to do this.  Basically, the
>> >>> interface needs to be changed slightly so that the random numbers are
>> >>> drawn
>> >>> in a fixed order, and that might mean one call to get any additional
>> >>> random
>> >>> numbers in a pricer, which gets called in a critical section, and
>> >>> another to
>> >>> run the pricer with the random numbers.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> October Webinars: Code for Performance
>> >>> Free Intel webinars can help you accelerate application performance.
>> >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> >>> most
>> >>> from
>> >>> the latest Intel processors and coprocessors. See abstracts and
>> >>> register
>> >>> >
>> >>>
>> >>>
>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> QuantLib-dev mailing list
>> >>> Qua...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >>>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> October Webinars: Code for Performance
>> >> Free Intel webinars can help you accelerate application performance.
>> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> >> most
>> >> from
>> >> the latest Intel processors and coprocessors. See abstracts and
>> >> register >
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> >>
>> >> _______________________________________________
>> >> QuantLib-dev mailing list
>> >> Qua...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > October Webinars: Code for Performance
>> > Free Intel webinars can help you accelerate application performance.
>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> > from
>> > the latest Intel processors and coprocessors. See abstracts and register
>> > >
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > QuantLib-dev mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >
>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] Openmp work on mcarlo

[Joseph W. <joe...@gm...>]

Can we move onto the main tree any changes that don't break backward
compatibility and then leave anything that does break compatibility on the
outside until we figure out what the best way of handling things are?

If we default openmp to off, then the changes to lattice and fd give some
speedups without breaking compatbility.  We can then work on the things
that break compatibility separately.  Parallelzing mcarlo turns out to be
extremely tricky so I want to work on it separately.  In particular, I want
to make absolutely sure that there is no way we can still maintain backward
compatibility.

When I worked on a similar problem on a different code base, we managed to
preserve backward compatibility, but is was a really, really hard slog
involving a lot of very delicate coding.  If I can play with the code for a
while, it might be possible to do the same thing.



On Tue, Oct 22, 2013 at 6:13 PM, Luigi Ballabio <lui...@gm...>wrote:

> Hi Joseph,
>     it will probably be a while before we add to the main branch any
> changes that break backward compatibility.  How about I create a
> long-lived branch for your changes and I pull your changes there? The
> advantage would be that your code might be found more easily. On the
> other hand, the disadvantage is that pull requests from other people
> might get made against my repo, not yours, even though the right
> person to manage them would be you instead; this would be easier if
> your fork was the reference for further development.
>
> Just let me know what you prefer.
>
> Later,
>     Luigi
>
>
>
> On Tue, Oct 22, 2013 at 4:51 AM, Joseph Wang <joe...@gm...> wrote:
> > It's possible to figure out the number of random number evaluations, and
> > then skip ahead N evaluations for each thread.  In practice this works
> but
> > the code is very fragile.  Having each thread have its own state is also
> > used but it requires the user to know ahead of time how many threads to
> use,
> > and you have to be very careful not to introduce bad correlations.
> >
> > I'm trying to get deterministic order by putting the RNG into a critical
> > section.  Right now the goal isn't to get the same order between non-OMP
> and
> > OMP but to at least get identical answers between different OMP runs.
>  This
> > isn't a hard algorithm issue, but its a C++ class/architecture issue,
> since
> > it involves changing the interface of the MC classes, and I'd like to get
> > this right before moving anything to the main code branch.
> >
> > One other technique that I've see is to generate all of the paths ahead
> of
> > time, store in memory and the run the pricing afterwards.  This gets you
> > deterministic ordering, and you can do clever things with RNG, and it's
> very
> > useful for generating greeks, but you then have to carefully manage
> memory,
> > and I want to avoid that.
> >
> > I've been able to get nice speedups with OpenMP with FD and lattice, and
> I'd
> > appreciate it if people could test the patches (openmp branch on
> > joequant/quantlib github).  One thing that MP does is favor simple
> schemes
> > so I've parallelized those.  There are some well known MP algorithms for
> > tridiagonalizing a matrix and I can implement that once MC gets put in.
> >
> >
> >
> > On Tue, Oct 22, 2013 at 4:31 AM, Kyle Schlansker <ky...@th...>
> > wrote:
> >>
> >> I think the standard solution is to have each thread maintain its own
> >> state (i.e. rand seed).
> >>
> >> Having a shared q, lock free or not, would then introduce nondeterminism
> >> unless all consumer threads read from that q in the same order from run
> to
> >> run, which it seems is not guaranteed.
> >>
> >> --
> >> kyle
> >>
> >> Sent from my mobile; apologies for any deficiencies of spelling or
> message
> >> tone.
> >>
> >> On Oct 21, 2013, at 2:53 PM, Mike Sharpe <ma...@gm...> wrote:
> >>
> >> Does the number of random numbers needed per iteration change or is it a
> >> constant amount?
> >>
> >> Would it be possible to encapsulate the random generator state so each
> >> thread could own its own RNG?
> >>
> >> If that isn't feasible or reduces the quality of the generation, would
> it
> >> be possible to spawn a producer thread that pushes random numbers onto a
> >> queue (could even investigate boost::lockfree::queue to avoid locking,
> >> though it requires boost 1.53) and have the worker thread just pop off
> from
> >> that queue whenever a new random number is needed?
> >>
> >> Mike
> >>
> >>
> >> On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...>
> wrote:
> >>>
> >>> I've done some more parallelization with openmp and quantlib.  I've
> >>> uploaded the changes to the https://github.com/joequant/quantlib.  The
> >>> branch openmp has some changes that I've issued a pull-request for.
> >>> openmp-mcario has some changes that need some more work.
> >>>
> >>> I've gotten the MC to work by generating the paths in a critical
> >>> situation.  Calculating the prices once I have the path is
> multithreaded,
> >>> but right now I need to generate the paths in a single thread to make
> sure
> >>> that the same sequence is generated.
> >>>
> >>> The big issue right now is that there is a race condition in the
> >>> calculation of barrier options which is causing one regression test to
> fail.
> >>> The problem is that the random number generator is being called in
> >>> BarrierPathPricer, and since that is run multithread, the sequence
> that is
> >>> being pulled will change from run to run based on whether other paths
> have
> >>> pulled random numbers already.
> >>>
> >>> I think that fixing this is going to need some code restructuring, but
> >>> I'd like to get some thoughts as to how to do this.  Basically, the
> >>> interface needs to be changed slightly so that the random numbers are
> drawn
> >>> in a fixed order, and that might mean one call to get any additional
> random
> >>> numbers in a pricer, which gets called in a critical section, and
> another to
> >>> run the pricer with the random numbers.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> October Webinars: Code for Performance
> >>> Free Intel webinars can help you accelerate application performance.
> >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most
> >>> from
> >>> the latest Intel processors and coprocessors. See abstracts and
> register
> >>> >
> >>>
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> QuantLib-dev mailing list
> >>> Qua...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >>>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> October Webinars: Code for Performance
> >> Free Intel webinars can help you accelerate application performance.
> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> >> from
> >> the latest Intel processors and coprocessors. See abstracts and
> register >
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> QuantLib-dev mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>

Re: [Quantlib-dev] Openmp work on mcarlo

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

Hi Joseph,
    it will probably be a while before we add to the main branch any
changes that break backward compatibility.  How about I create a
long-lived branch for your changes and I pull your changes there? The
advantage would be that your code might be found more easily. On the
other hand, the disadvantage is that pull requests from other people
might get made against my repo, not yours, even though the right
person to manage them would be you instead; this would be easier if
your fork was the reference for further development.

Just let me know what you prefer.

Later,
    Luigi



On Tue, Oct 22, 2013 at 4:51 AM, Joseph Wang <joe...@gm...> wrote:
> It's possible to figure out the number of random number evaluations, and
> then skip ahead N evaluations for each thread.  In practice this works but
> the code is very fragile.  Having each thread have its own state is also
> used but it requires the user to know ahead of time how many threads to use,
> and you have to be very careful not to introduce bad correlations.
>
> I'm trying to get deterministic order by putting the RNG into a critical
> section.  Right now the goal isn't to get the same order between non-OMP and
> OMP but to at least get identical answers between different OMP runs.  This
> isn't a hard algorithm issue, but its a C++ class/architecture issue, since
> it involves changing the interface of the MC classes, and I'd like to get
> this right before moving anything to the main code branch.
>
> One other technique that I've see is to generate all of the paths ahead of
> time, store in memory and the run the pricing afterwards.  This gets you
> deterministic ordering, and you can do clever things with RNG, and it's very
> useful for generating greeks, but you then have to carefully manage memory,
> and I want to avoid that.
>
> I've been able to get nice speedups with OpenMP with FD and lattice, and I'd
> appreciate it if people could test the patches (openmp branch on
> joequant/quantlib github).  One thing that MP does is favor simple schemes
> so I've parallelized those.  There are some well known MP algorithms for
> tridiagonalizing a matrix and I can implement that once MC gets put in.
>
>
>
> On Tue, Oct 22, 2013 at 4:31 AM, Kyle Schlansker <ky...@th...>
> wrote:
>>
>> I think the standard solution is to have each thread maintain its own
>> state (i.e. rand seed).
>>
>> Having a shared q, lock free or not, would then introduce nondeterminism
>> unless all consumer threads read from that q in the same order from run to
>> run, which it seems is not guaranteed.
>>
>> --
>> kyle
>>
>> Sent from my mobile; apologies for any deficiencies of spelling or message
>> tone.
>>
>> On Oct 21, 2013, at 2:53 PM, Mike Sharpe <ma...@gm...> wrote:
>>
>> Does the number of random numbers needed per iteration change or is it a
>> constant amount?
>>
>> Would it be possible to encapsulate the random generator state so each
>> thread could own its own RNG?
>>
>> If that isn't feasible or reduces the quality of the generation, would it
>> be possible to spawn a producer thread that pushes random numbers onto a
>> queue (could even investigate boost::lockfree::queue to avoid locking,
>> though it requires boost 1.53) and have the worker thread just pop off from
>> that queue whenever a new random number is needed?
>>
>> Mike
>>
>>
>> On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...> wrote:
>>>
>>> I've done some more parallelization with openmp and quantlib.  I've
>>> uploaded the changes to the https://github.com/joequant/quantlib.  The
>>> branch openmp has some changes that I've issued a pull-request for.
>>> openmp-mcario has some changes that need some more work.
>>>
>>> I've gotten the MC to work by generating the paths in a critical
>>> situation.  Calculating the prices once I have the path is multithreaded,
>>> but right now I need to generate the paths in a single thread to make sure
>>> that the same sequence is generated.
>>>
>>> The big issue right now is that there is a race condition in the
>>> calculation of barrier options which is causing one regression test to fail.
>>> The problem is that the random number generator is being called in
>>> BarrierPathPricer, and since that is run multithread, the sequence that is
>>> being pulled will change from run to run based on whether other paths have
>>> pulled random numbers already.
>>>
>>> I think that fixing this is going to need some code restructuring, but
>>> I'd like to get some thoughts as to how to do this.  Basically, the
>>> interface needs to be changed slightly so that the random numbers are drawn
>>> in a fixed order, and that might mean one call to get any additional random
>>> numbers in a pricer, which gets called in a critical section, and another to
>>> run the pricer with the random numbers.
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and register
>>> >
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] Openmp work on mcarlo

[Joseph W. <joe...@gm...>]

It's possible to figure out the number of random number evaluations, and
then skip ahead N evaluations for each thread.  In practice this works but
the code is very fragile.  Having each thread have its own state is also
used but it requires the user to know ahead of time how many threads to
use, and you have to be very careful not to introduce bad correlations.

I'm trying to get deterministic order by putting the RNG into a critical
section.  Right now the goal isn't to get the same order between non-OMP
and OMP but to at least get identical answers between different OMP runs.
This isn't a hard algorithm issue, but its a C++ class/architecture issue,
since it involves changing the interface of the MC classes, and I'd like to
get this right before moving anything to the main code branch.

One other technique that I've see is to generate all of the paths ahead of
time, store in memory and the run the pricing afterwards.  This gets you
deterministic ordering, and you can do clever things with RNG, and it's
very useful for generating greeks, but you then have to carefully manage
memory, and I want to avoid that.

I've been able to get nice speedups with OpenMP with FD and lattice, and
I'd appreciate it if people could test the patches (openmp branch on
joequant/quantlib github).  One thing that MP does is favor simple schemes
so I've parallelized those.  There are some well known MP algorithms for
tridiagonalizing a matrix and I can implement that once MC gets put in.



On Tue, Oct 22, 2013 at 4:31 AM, Kyle Schlansker <ky...@th...>wrote:

> I think the standard solution is to have each thread maintain its own
> state (i.e. rand seed).
>
> Having a shared q, lock free or not, would then introduce nondeterminism
> unless all consumer threads read from that q in the same order from run to
> run, which it seems is not guaranteed.
>
> --
> kyle
>
> Sent from my mobile; apologies for any deficiencies of spelling or message
> tone.
>
> On Oct 21, 2013, at 2:53 PM, Mike Sharpe <ma...@gm...> wrote:
>
> Does the number of random numbers needed per iteration change or is it a
> constant amount?
>
> Would it be possible to encapsulate the random generator state so each
> thread could own its own RNG?
>
> If that isn't feasible or reduces the quality of the generation, would it
> be possible to spawn a producer thread that pushes random numbers onto a
> queue (could even investigate boost::lockfree::queue to avoid locking,
> though it requires boost 1.53) and have the worker thread just pop off from
> that queue whenever a new random number is needed?
>
> Mike
>
>
> On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...> wrote:
>
>> I've done some more parallelization with openmp and quantlib.  I've
>> uploaded the changes to the https://github.com/joequant/quantlib.  The
>> branch openmp has some changes that I've issued a pull-request for.
>> openmp-mcario has some changes that need some more work.
>>
>> I've gotten the MC to work by generating the paths in a critical
>> situation.  Calculating the prices once I have the path is multithreaded,
>> but right now I need to generate the paths in a single thread to make sure
>> that the same sequence is generated.
>>
>> The big issue right now is that there is a race condition in the
>> calculation of barrier options which is causing one regression test to
>> fail.  The problem is that the random number generator is being called in
>> BarrierPathPricer, and since that is run multithread, the sequence that is
>> being pulled will change from run to run based on whether other paths have
>> pulled random numbers already.
>>
>> I think that fixing this is going to need some code restructuring, but
>> I'd like to get some thoughts as to how to do this.  Basically, the
>> interface needs to be changed slightly so that the random numbers are drawn
>> in a fixed order, and that might mean one call to get any additional random
>> numbers in a pricer, which gets called in a critical section, and another
>> to run the pricer with the random numbers.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Re: [Quantlib-dev] Openmp work on mcarlo

[Kyle S. <ky...@th...>]

I think the standard solution is to have each thread maintain its own state
(i.e. rand seed).

Having a shared q, lock free or not, would then introduce nondeterminism
unless all consumer threads read from that q in the same order from run to
run, which it seems is not guaranteed.

--
kyle

Sent from my mobile; apologies for any deficiencies of spelling or message
tone.

On Oct 21, 2013, at 2:53 PM, Mike Sharpe <ma...@gm...> wrote:

Does the number of random numbers needed per iteration change or is it a
constant amount?

Would it be possible to encapsulate the random generator state so each
thread could own its own RNG?

If that isn't feasible or reduces the quality of the generation, would it
be possible to spawn a producer thread that pushes random numbers onto a
queue (could even investigate boost::lockfree::queue to avoid locking,
though it requires boost 1.53) and have the worker thread just pop off from
that queue whenever a new random number is needed?

Mike


On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...> wrote:

> I've done some more parallelization with openmp and quantlib.  I've
> uploaded the changes to the https://github.com/joequant/quantlib.  The
> branch openmp has some changes that I've issued a pull-request for.
> openmp-mcario has some changes that need some more work.
>
> I've gotten the MC to work by generating the paths in a critical
> situation.  Calculating the prices once I have the path is multithreaded,
> but right now I need to generate the paths in a single thread to make sure
> that the same sequence is generated.
>
> The big issue right now is that there is a race condition in the
> calculation of barrier options which is causing one regression test to
> fail.  The problem is that the random number generator is being called in
> BarrierPathPricer, and since that is run multithread, the sequence that is
> being pulled will change from run to run based on whether other paths have
> pulled random numbers already.
>
> I think that fixing this is going to need some code restructuring, but I'd
> like to get some thoughts as to how to do this.  Basically, the interface
> needs to be changed slightly so that the random numbers are drawn in a
> fixed order, and that might mean one call to get any additional random
> numbers in a pricer, which gets called in a critical section, and another
> to run the pricer with the random numbers.
>
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

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

Re: [Quantlib-dev] Openmp work on mcarlo

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

Does the number of random numbers needed per iteration change or is it a
constant amount?

Would it be possible to encapsulate the random generator state so each
thread could own its own RNG?

If that isn't feasible or reduces the quality of the generation, would it
be possible to spawn a producer thread that pushes random numbers onto a
queue (could even investigate boost::lockfree::queue to avoid locking,
though it requires boost 1.53) and have the worker thread just pop off from
that queue whenever a new random number is needed?

Mike


On Sun, Oct 20, 2013 at 7:01 AM, Joseph Wang <joe...@gm...> wrote:

> I've done some more parallelization with openmp and quantlib.  I've
> uploaded the changes to the https://github.com/joequant/quantlib.  The
> branch openmp has some changes that I've issued a pull-request for.
> openmp-mcario has some changes that need some more work.
>
> I've gotten the MC to work by generating the paths in a critical
> situation.  Calculating the prices once I have the path is multithreaded,
> but right now I need to generate the paths in a single thread to make sure
> that the same sequence is generated.
>
> The big issue right now is that there is a race condition in the
> calculation of barrier options which is causing one regression test to
> fail.  The problem is that the random number generator is being called in
> BarrierPathPricer, and since that is run multithread, the sequence that is
> being pulled will change from run to run based on whether other paths have
> pulled random numbers already.
>
> I think that fixing this is going to need some code restructuring, but I'd
> like to get some thoughts as to how to do this.  Basically, the interface
> needs to be changed slightly so that the random numbers are drawn in a
> fixed order, and that might mean one call to get any additional random
> numbers in a pricer, which gets called in a critical section, and another
> to run the pricer with the random numbers.
>
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

[Quantlib-dev] Openmp work on mcarlo

[Joseph W. <joe...@gm...>]

I've done some more parallelization with openmp and quantlib.  I've
uploaded the changes to the https://github.com/joequant/quantlib.  The
branch openmp has some changes that I've issued a pull-request for.
openmp-mcario has some changes that need some more work.

I've gotten the MC to work by generating the paths in a critical
situation.  Calculating the prices once I have the path is multithreaded,
but right now I need to generate the paths in a single thread to make sure
that the same sequence is generated.

The big issue right now is that there is a race condition in the
calculation of barrier options which is causing one regression test to
fail.  The problem is that the random number generator is being called in
BarrierPathPricer, and since that is run multithread, the sequence that is
being pulled will change from run to run based on whether other paths have
pulled random numbers already.

I think that fixing this is going to need some code restructuring, but I'd
like to get some thoughts as to how to do this.  Basically, the interface
needs to be changed slightly so that the random numbers are drawn in a
fixed order, and that might mean one call to get any additional random
numbers in a pricer, which gets called in a critical section, and another
to run the pricer with the random numbers.

Re: [Quantlib-dev] test suite errors (VC9, boost 1.52)

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

Hi Nando,

I've (hopefully) fixed it, see

https://github.com/lballabio/quantlib/pull/46

but I can't test it because I don't have access to VC9. It would be greate if 
you could test it.

thanks a lot
 Klaus

On Friday, October 18, 2013 07:39:59 PM Peter Caspers wrote:

Hi Nando,
 
there are. I added a fix for Error2 to
 
https://github.com/lballabio/quantlib/pull/44
 
I would be great if you could confirm that this does the trick.
 
thanks a lot and regards
    Peter



On 18 October 2013 12:52, Ferdinando M. Ametrano <fer...@am...> 
wrote:

Hi all


I've just noticed two errors in the test-suite: my git clone of 
fballabio, VC9, boost 1.52


Error	1	fatal error in 
"QuantLib::detail::quantlib_test_case(&FdHestonTest::testSquareRootEvolveWithStationaryDensity)": 
std::exception: interpolation range is [0.118827, 0.304616]: extrapolation at 
0.118827 not allowed	unknown location

Error	2	fatal error in 
"QuantLib::detail::quantlib_test_case(&MarkovFunctionalTest::testKahaleSmileSection)": 
Invalid parameter detected by C runtime library	unknown location 


I cannot personally look into it for the time being, but I'm sure there are 
braver souls out there...


ciao -- Nando


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] test suite errors (VC9, boost 1.52)

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

Hi Nando,

there are. I added a fix for Error2 to

https://github.com/lballabio/quantlib/pull/44

I would be great if you could confirm that this does the trick.

thanks a lot and regards
    Peter


On 18 October 2013 12:52, Ferdinando M. Ametrano <fer...@am...>wrote:

> Hi all
>
> I've just noticed two errors in the test-suite: my git clone of
> fballabio, VC9, boost 1.52
>
> Error 1 fatal error in
> "QuantLib::detail::quantlib_test_case(&FdHestonTest::testSquareRootEvolveWithStationaryDensity)":
> std::exception: interpolation range is [0.118827, 0.304616]: extrapolation
> at 0.118827 not allowed unknown location
> Error 2 fatal error in
> "QuantLib::detail::quantlib_test_case(&MarkovFunctionalTest::testKahaleSmileSection)":
> Invalid parameter detected by C runtime library unknown location
>
> I cannot personally look into it for the time being, but I'm sure there
> are braver souls out there...
>
> ciao -- Nando
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>