quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] QuantLib-SWIG, the observer pattern and destructor call during update

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

Hi Luigi,

I haven't fully worked this one out, but I think that it is possible to
some progress on this by making the destructor of the Observer class
private and then creating some helper classes (probably inheriting from
shared_pointer) that are friends of Observer and define proper clean
order, i.e., disconnect the Observables before starting the main
destruction.

This approach would enforce code correctness at compile time (because
non-safe destruction of Observer objects would be a compile time error)
but would obviously require changes to existing code. It should play
fairly well with SWIG which is I think already aware of the implications
of a private destructor.

There is no less invasive way I can think of at moment -- the goal of
having easy composition of objects in C++ makes it very hard to re-order
destruction operations! Possibly one can do something very clever with
clone()-able objects and overriding the operator new() for Observer but
that would be getting really complicated....

Best,
Bojan

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

Re: [Quantlib-dev] QuantLib-SWIG, the observer pattern and destructor call during update

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

On Wed, Feb 29, 2012 at 4:51 PM, Ferdinando Ametrano <na...@am...> wrote:
> I wonder if it would be more effective to just live with the fact that
> QuantLib 1.x is not thread-safe and start a parallel
> non-backward-compatible QuantLib 2.x ?

That's a possibility (and seeing the number of issues we'll have to
address for 2.0, we'll also have to discuss whether to keep using
Subversion or move to a DVCS).

However, the problem is that even if one doesn't use threads, as soon
as one uses QuantLib in Java or C# the system is going to run the
garbage collector in another thread.
So until a 2.0 is out, version 1.x is pretty much unusable from those
languages for anything else than toy programs.

Luigi


> We might use 2.x for an overall library re-factoring, with the spotlight on
> 1) thread-safety
> 2) parallelism
> 3) increased boost-ification (math, distributions, date, random
> numbers, optional, etc)
> 4) review of few issues about Instrument/Pricing engines, etc
> 5) interface clean-up removing methods which can be implemented as functions
> 6) review of the worst performance bottlenecks (e.g. virtual
> Event::hasOccurred, etc)
> 7) fix the non invertible relation between dates and times in TermStructure
> 8) etc
>
> ciao -- Nando
>
> On Wed, Feb 29, 2012 at 12:45 PM, Luigi Ballabio
> <lui...@gm...> wrote:
>> Hi all,
>>    recently Klaus Spanderen has posted on his blog about the
>> Observer/Observable problems we had when QuantLib is exported through
>> SWIG to a language like Java or C# which run garbage collection in a
>> separate thread (see
>> <http://old.nabble.com/Issues-with-C--Swig-Bindings,-NUnit-and-Settings.instance%28%29.setEvaluationDate%28%29-td30549787.html>
>> for the original thread and
>> <http://hpcquantlib.wordpress.com/2012/02/27/quantlib-swig-and-a-thread-safe-observer-pattern-in-c/>
>> for Klaus' post).
>>
>> I've been thinking about it for the last few months, too.  I haven't a
>> full solution (I guess the real solution would be to rewrite the whole
>> thing in terms of Boost.Signal2, which is thread-safe) but here's what
>> I got so far.
>>
>> The original problem is that we've gone against one of the basic
>> tenets of C++, namely, that release of resources should go in the
>> inverse order as their acquisition. What happens now is that observers
>> unregister themselves in the destructor they inherit from the base
>> Observer class, which results in the following sequence of actions:
>>
>> On construction:
>> - call the Observer constructor, which builds the base-class part of
>> the instance;
>> - call the derived-class constructor, which builds the derived-class
>> attributes and stuff;
>> - inside the derived-class constructor, register with the observables.
>>
>> On destruction:
>> - call the derived-class destructor, which destroys the derived-class
>> attributes and stuff;
>> - call the Observer destructor, which unregisters with the observables...
>> - ...and then destroys the base-class part of the instance.
>>
>> The problem is that we have a-b-c during construction and b-c-a during
>> destruction (it should be c-b-a).  Doing it this way, sometimes it
>> happens that an observable sends a notification between b and c. The
>> observer is not yet unregistered, so it gets the notification; but
>> since it's already been partially destroyed, the resulting call to
>> update() results in a crash.
>>
>> Both Henner and Klaus did their best to fix the Observer class, but I
>> think the solution is to do things in the correct order (c-b-a), that
>> is, unregister in the destructor of the derived class.  But how?
>> Forcing one to write the calls to unregisterWith() inside the
>> destructor (and often, to write an explicit destructor just for that)
>> cannot be enforced, and would result in dangling pointers as soon as
>> one forgets to do it.
>>
>> One way might be to use RAII to do this.  We might implement a helper
>> class like:
>>
>> template <class T>
>> class Registered {
>>    T observable_;
>>    Observer* observer_;
>>  public:
>>    Registered(const T& observable, Observer* observer)
>>    : observable_(observable), observer_(observer) {
>>        observer_->registerWith(observable_);
>>    }
>>    ~Registered() {
>>        observer_->unregisterWith(observable_);
>>    }
>>    const T& operator->() const { return observable_; }
>> };
>>
>> that wraps an observable and manages unregistration.  This way,
>> instead of writing derived observer classes as:
>>
>> class SomeClass {
>>    Handle<YieldTermStructure> ts_;
>>  public:
>>    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts) {
>>        registerWith(ts_);
>>    }
>> };
>>
>> we would write:
>>
>> class SomeClass {
>>    Registered<Handle<YieldTermStructure> > ts_;
>>  public:
>>    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts, this) {}
>> };
>>
>> This way, ts_ is a Registered instance (which provides an
>> operator->(), so it can be used as before; for instance,
>> ts_->discount(t) still works) and when SomeClass is destroyed, the
>> unregisterWith call in the Registered destructor will fire during the
>> destruction of SomeClass, doing things in the correct order.
>>
>> (Note: it would also be possible to work out things so that we can
>> leave the registerWith() call in the constructor, if we want to modify
>> the least possible amount of code. When called with a Registered as an
>> argument, it would register the observer with the wrapped observable
>> and store the observer's "this" pointer into the Registered instance.)
>> (Note 2: "Registered" might not be the best name.  "Observed", maybe?)
>>
>>
>> Unfortunately, it's not foolproof.  For instance, the Registered
>> instances are better declared last in the class; and even in that
>> case, if we have two Registered (A and B) there might be freak
>> scenarios in which A is unregistered and destroyed, and before B can
>> be unregistered it fires a notification.  If the observer's update()
>> method just flips a bool, it will work fine; but if update() tries to
>> access A instead, it will find it destroyed and hilarity will ensue.
>>
>> Also, we would still have the problem that an observer might be
>> removed from an observable's registered list while the observable is
>> iterating over it in notifyObservers().  We'll need a lock to prevent
>> that.
>>
>> I guess this about wraps it up.  Thoughts?
>>
>> Later,
>>    Luigi
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] QuantLib-SWIG, the observer pattern and destructor call during update

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

Hi all

I wonder if it would be more effective to just live with the fact that
QuantLib 1.x is not thread-safe and start a parallel
non-backward-compatible QuantLib 2.x ?

We might use 2.x for an overall library re-factoring, with the spotlight on
1) thread-safety
2) parallelism
3) increased boost-ification (math, distributions, date, random
numbers, optional, etc)
4) review of few issues about Instrument/Pricing engines, etc
5) interface clean-up removing methods which can be implemented as functions
6) review of the worst performance bottlenecks (e.g. virtual
Event::hasOccurred, etc)
7) fix the non invertible relation between dates and times in TermStructure
8) etc

ciao -- Nando

On Wed, Feb 29, 2012 at 12:45 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Hi all,
>    recently Klaus Spanderen has posted on his blog about the
> Observer/Observable problems we had when QuantLib is exported through
> SWIG to a language like Java or C# which run garbage collection in a
> separate thread (see
> <http://old.nabble.com/Issues-with-C--Swig-Bindings,-NUnit-and-Settings.instance%28%29.setEvaluationDate%28%29-td30549787.html>
> for the original thread and
> <http://hpcquantlib.wordpress.com/2012/02/27/quantlib-swig-and-a-thread-safe-observer-pattern-in-c/>
> for Klaus' post).
>
> I've been thinking about it for the last few months, too.  I haven't a
> full solution (I guess the real solution would be to rewrite the whole
> thing in terms of Boost.Signal2, which is thread-safe) but here's what
> I got so far.
>
> The original problem is that we've gone against one of the basic
> tenets of C++, namely, that release of resources should go in the
> inverse order as their acquisition. What happens now is that observers
> unregister themselves in the destructor they inherit from the base
> Observer class, which results in the following sequence of actions:
>
> On construction:
> - call the Observer constructor, which builds the base-class part of
> the instance;
> - call the derived-class constructor, which builds the derived-class
> attributes and stuff;
> - inside the derived-class constructor, register with the observables.
>
> On destruction:
> - call the derived-class destructor, which destroys the derived-class
> attributes and stuff;
> - call the Observer destructor, which unregisters with the observables...
> - ...and then destroys the base-class part of the instance.
>
> The problem is that we have a-b-c during construction and b-c-a during
> destruction (it should be c-b-a).  Doing it this way, sometimes it
> happens that an observable sends a notification between b and c. The
> observer is not yet unregistered, so it gets the notification; but
> since it's already been partially destroyed, the resulting call to
> update() results in a crash.
>
> Both Henner and Klaus did their best to fix the Observer class, but I
> think the solution is to do things in the correct order (c-b-a), that
> is, unregister in the destructor of the derived class.  But how?
> Forcing one to write the calls to unregisterWith() inside the
> destructor (and often, to write an explicit destructor just for that)
> cannot be enforced, and would result in dangling pointers as soon as
> one forgets to do it.
>
> One way might be to use RAII to do this.  We might implement a helper
> class like:
>
> template <class T>
> class Registered {
>    T observable_;
>    Observer* observer_;
>  public:
>    Registered(const T& observable, Observer* observer)
>    : observable_(observable), observer_(observer) {
>        observer_->registerWith(observable_);
>    }
>    ~Registered() {
>        observer_->unregisterWith(observable_);
>    }
>    const T& operator->() const { return observable_; }
> };
>
> that wraps an observable and manages unregistration.  This way,
> instead of writing derived observer classes as:
>
> class SomeClass {
>    Handle<YieldTermStructure> ts_;
>  public:
>    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts) {
>        registerWith(ts_);
>    }
> };
>
> we would write:
>
> class SomeClass {
>    Registered<Handle<YieldTermStructure> > ts_;
>  public:
>    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts, this) {}
> };
>
> This way, ts_ is a Registered instance (which provides an
> operator->(), so it can be used as before; for instance,
> ts_->discount(t) still works) and when SomeClass is destroyed, the
> unregisterWith call in the Registered destructor will fire during the
> destruction of SomeClass, doing things in the correct order.
>
> (Note: it would also be possible to work out things so that we can
> leave the registerWith() call in the constructor, if we want to modify
> the least possible amount of code. When called with a Registered as an
> argument, it would register the observer with the wrapped observable
> and store the observer's "this" pointer into the Registered instance.)
> (Note 2: "Registered" might not be the best name.  "Observed", maybe?)
>
>
> Unfortunately, it's not foolproof.  For instance, the Registered
> instances are better declared last in the class; and even in that
> case, if we have two Registered (A and B) there might be freak
> scenarios in which A is unregistered and destroyed, and before B can
> be unregistered it fires a notification.  If the observer's update()
> method just flips a bool, it will work fine; but if update() tries to
> access A instead, it will find it destroyed and hilarity will ensue.
>
> Also, we would still have the problem that an observer might be
> removed from an observable's registered list while the observable is
> iterating over it in notifyObservers().  We'll need a lock to prevent
> that.
>
> I guess this about wraps it up.  Thoughts?
>
> Later,
>    Luigi
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] QuantLib-SWIG, the observer pattern and destructor call during update

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

Hi all,
    recently Klaus Spanderen has posted on his blog about the
Observer/Observable problems we had when QuantLib is exported through
SWIG to a language like Java or C# which run garbage collection in a
separate thread (see
<http://old.nabble.com/Issues-with-C--Swig-Bindings,-NUnit-and-Settings.instance%28%29.setEvaluationDate%28%29-td30549787.html>
for the original thread and
<http://hpcquantlib.wordpress.com/2012/02/27/quantlib-swig-and-a-thread-safe-observer-pattern-in-c/>
for Klaus' post).

I've been thinking about it for the last few months, too.  I haven't a
full solution (I guess the real solution would be to rewrite the whole
thing in terms of Boost.Signal2, which is thread-safe) but here's what
I got so far.

The original problem is that we've gone against one of the basic
tenets of C++, namely, that release of resources should go in the
inverse order as their acquisition. What happens now is that observers
unregister themselves in the destructor they inherit from the base
Observer class, which results in the following sequence of actions:

On construction:
- call the Observer constructor, which builds the base-class part of
the instance;
- call the derived-class constructor, which builds the derived-class
attributes and stuff;
- inside the derived-class constructor, register with the observables.

On destruction:
- call the derived-class destructor, which destroys the derived-class
attributes and stuff;
- call the Observer destructor, which unregisters with the observables...
- ...and then destroys the base-class part of the instance.

The problem is that we have a-b-c during construction and b-c-a during
destruction (it should be c-b-a).  Doing it this way, sometimes it
happens that an observable sends a notification between b and c. The
observer is not yet unregistered, so it gets the notification; but
since it's already been partially destroyed, the resulting call to
update() results in a crash.

Both Henner and Klaus did their best to fix the Observer class, but I
think the solution is to do things in the correct order (c-b-a), that
is, unregister in the destructor of the derived class.  But how?
Forcing one to write the calls to unregisterWith() inside the
destructor (and often, to write an explicit destructor just for that)
cannot be enforced, and would result in dangling pointers as soon as
one forgets to do it.

One way might be to use RAII to do this.  We might implement a helper
class like:

template <class T>
class Registered {
    T observable_;
    Observer* observer_;
  public:
    Registered(const T& observable, Observer* observer)
    : observable_(observable), observer_(observer) {
        observer_->registerWith(observable_);
    }
    ~Registered() {
        observer_->unregisterWith(observable_);
    }
    const T& operator->() const { return observable_; }
};

that wraps an observable and manages unregistration.  This way,
instead of writing derived observer classes as:

class SomeClass {
    Handle<YieldTermStructure> ts_;
  public:
    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts) {
        registerWith(ts_);
    }
};

we would write:

class SomeClass {
    Registered<Handle<YieldTermStructure> > ts_;
  public:
    SomeClass(const Handle<YieldTermStructure>& ts) : ts_(ts, this) {}
};

This way, ts_ is a Registered instance (which provides an
operator->(), so it can be used as before; for instance,
ts_->discount(t) still works) and when SomeClass is destroyed, the
unregisterWith call in the Registered destructor will fire during the
destruction of SomeClass, doing things in the correct order.

(Note: it would also be possible to work out things so that we can
leave the registerWith() call in the constructor, if we want to modify
the least possible amount of code. When called with a Registered as an
argument, it would register the observer with the wrapped observable
and store the observer's "this" pointer into the Registered instance.)
(Note 2: "Registered" might not be the best name.  "Observed", maybe?)


Unfortunately, it's not foolproof.  For instance, the Registered
instances are better declared last in the class; and even in that
case, if we have two Registered (A and B) there might be freak
scenarios in which A is unregistered and destroyed, and before B can
be unregistered it fires a notification.  If the observer's update()
method just flips a bool, it will work fine; but if update() tries to
access A instead, it will find it destroyed and hilarity will ensue.

Also, we would still have the problem that an observer might be
removed from an observable's registered list while the observable is
iterating over it in notifyObservers().  We'll need a lock to prevent
that.

I guess this about wraps it up.  Thoughts?

Later,
    Luigi

Re: [Quantlib-dev] Will Quantlib Attend Google Summer of Code?

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

On Sat, Feb 18, 2012 at 3:47 PM, xiangyu <xia...@qq...> wrote:
> Hi, will Quantlib Attend this year's Google Summer of Code?
>
> http://www.google-melange.com/gsoc/events/google/gsoc2012

Hi,
    personally I won't have time to mentor, but it anyone else
volunteers to do it I'll be glad to give support on the organizational
side.

Luigi

Re: [Quantlib-dev] Google Summer of Code

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

On Sun, Feb 19, 2012 at 11:29 PM, Alok <qua...@bi...> wrote:
> p.s. I notice that there is a nice GitHub QuantLib repository at
> https://github.com/lballabio/quantlib/commits/master I wonder how far
> behind or incomplete it is from the project svn repository at
> https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
> checkout from svn trunk clocked at 573MB. And I guess that with a few
> more MBs I might as well get the whole project history offline from
> GitHub instead of running expensive svn checkouts.

It's up to date; I have a cron job that pushes from subversion to
github nightly.
Note that the github repository contains only the QuantLib module,
though.  The subversion trunk also includes the SWIG wrappers and all
the modules that make up the QuantLibXL project.

Luigi

[Quantlib-dev] [ quantlib-Bugs-3492623 ] cannot open file

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

Bugs item #3492623, was opened at 2012-02-23 18:01
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3492623&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: Rejected
Priority: 5
Private: No
Submitted By: lorical (lorical)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot open file

Initial Comment:
LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc100-mt-1_47.lib'
------ Build started: Project: MarketModels, Configuration: Release Win32 ------
  MarketModels.cpp
  MarketModels_vc10.vcxproj -> C:\Documents and Settings\user\My Documents\QuantLib-1.1\QuantLib-1.1\Examples\MarketModels\.\bin\MarketModels-vc100-mt.exe
========== Build: 14 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
        I've tried to Build twice so far and same error occurs

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2012-02-24 01:06

Message:
Not a bug of the library.  Before compiling the QuantLib test suite, you
have to install the Boost libraries and set their path into the VC++
preferences.  See <http://quantlib.org/install/vc10.shtml> for
instructions.

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

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

[Quantlib-dev] [ quantlib-Bugs-3492623 ] cannot open file

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

Bugs item #3492623, was opened at 2012-02-23 18:01
Message generated for change (Tracker Item Submitted) made by lorical
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3492623&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: lorical (lorical)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot open file

Initial Comment:
LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc100-mt-1_47.lib'
------ Build started: Project: MarketModels, Configuration: Release Win32 ------
  MarketModels.cpp
  MarketModels_vc10.vcxproj -> C:\Documents and Settings\user\My Documents\QuantLib-1.1\QuantLib-1.1\Examples\MarketModels\.\bin\MarketModels-vc100-mt.exe
========== Build: 14 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
        I've tried to Build twice so far and same error occurs

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

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

Re: [Quantlib-dev] getting started as a developer for quantlib

[xiang w. <xia...@gm...>]

Hi all, I'm also reading the QuantLib code and happy to work on the QuantLib

Best regrads,

2012/2/21 Nicholas Pezolano <npe...@gm...>

> Hi I'm interested in contributing to the QuantLib project , if any one has
> any projects they need help with i would be more then happy to work on it.
>
> Best,
> --
> Nicholas Pezolano
> Department of Applied Math & Statistics
> State University of New York at Stony Brook
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

[Quantlib-dev] [ quantlib-Feature Requests-2962706 ] Delta Ladder call

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

Feature Requests item #2962706, was opened at 2010-03-03 08:35
Message generated for change (Comment added) made by npezolano
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=2962706&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
Priority: 5
Private: No
Submitted By: Vlad F (vladfelder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Delta Ladder call

Initial Comment:
Ability to make a simple call to extract "delta ladder"

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

Comment By: Nicholas Pezolano (npezolano)
Date: 2012-02-20 21:11

Message:
Hi Vlad if you email me background information on this i will try to
implement it

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

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

[Quantlib-dev] getting started as a developer for quantlib

[Nicholas P. <npe...@gm...>]

Hi I'm interested in contributing to the QuantLib project , if any one has
any projects they need help with i would be more then happy to work on it.

Best,
-- 
Nicholas Pezolano
Department of Applied Math & Statistics
State University of New York at Stony Brook

Re: [Quantlib-dev] Google Summer of Code

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

On 20 February 2012 at 00:06, Alok wrote:
| On Sun, Feb 19, 2012 at 11:18 PM, Dirk Eddelbuettel <ed...@de...> wrote:
| >
| > On 19 February 2012 at 22:58, Alok wrote:
| > | So I've explored the SourceForge project page some more and found the
| > | feature requests page on the tracker. And this entry by
| > | Nobody/Anonymous (nobody) struck me as interesting.
| > |
| > | http://sourceforge.net/tracker/?func=detail&aid=1651713&group_id=12740&atid=362740
| > |
| > | I would appreciate it very much if someone can elaborate on what sort
| > | of extension would someone be looking for. I do know that RQuantLib
| > | was developed as a Summer of Code project to extend QuantLib to the
| > | R-Project in 2009.
| >
| > I was about to comment on this (as I was the person suggesting that work and
| > the mentor -- that project worked out well).
| 
| Would you be interested in mentoring for the Google Summer of Code
| again? I see from the RQuantLib page
| http://dirk.eddelbuettel.com/code/rquantlib.html that: "There are lots
| more financial instruments covered in QuantLib. RQuantLib should grow
| to accomodate these. Help in writing the R wrappers would accelerate
| the provision of RQuantLib hooks for these."
| 
| How is the coverage of RQuantLib now? I am eager for an opportunity in
| extending QuantLib for either R or ROOT. What is your view on this?

I am always looking for people with C++ and R skills to help on RQuantLib. 
It is a terrific little project with still too little coverage of QuantLib.

It has spawned off Rcpp (as a generic C++ to R and back wrapping mechanism)
which soaked up most of my (and Romain's) time over the last few years. 

If you are interested, and have the skills to work on this, the R Project has
been a steady participant in GSoC. So you could apply there, and we could work
something out for RQuantLib. That said, it may of interest to get QL over
into GSoC in same form too.  

As for ROOT, I can't comment as I only know of it, but have never used it in
any capacity.

Dirk
 
| >
| > We could possibly have people work in QL under different umbrella
| > organisations too.  I know Portland St often provided a home.
| >
| > The real shortage may be on skilled mentors with a little bit of time. Google
| > Summer of Code is a nice program, and it could fit for QuantLib Extension
| > Proposals.
| >
| > Dirk
| >
| >
| > | Any ideas/thoughts/advise regarding this would be much appreciated.
| > |
| > | best regards,
| > | Alok
| > |
| > | On Sun, Feb 19, 2012 at 10:29 PM, Alok <qua...@bi...> wrote:
| > | > Hello,
| > | >
| > | > Google has announced its Summer of Code again for this year
| > | > http://www.google-melange.com/gsoc/homepage/google/gsoc2012 . And I
| > | > was wondering if there are any ideas for QuantLib projects for this
| > | > program. I would love to hear from prospective mentors about
| > | > challenges that an experienced C++ developer can contribute towards
| > | > this effort for 2-3 months over the summer. Please do respond even if
| > | > you don't have the time to participate in the program. I'll collect
| > | > ideas from the responses and post it onto a handy wiki page for later
| > | > use.
| > | >
| > | > p.s. I notice that there is a nice GitHub QuantLib repository at
| > | > https://github.com/lballabio/quantlib/commits/master I wonder how far
| > | > behind or incomplete it is from the project svn repository at
| > | > https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
| > | > checkout from svn trunk clocked at 573MB. And I guess that with a few
| > | > more MBs I might as well get the whole project history offline from
| > | > GitHub instead of running expensive svn checkouts.
| > | >
| > | > best regards,
| > | > Alok
| > |
| > | ------------------------------------------------------------------------------
| > | Virtualization & Cloud Management Using Capacity Planning
| > | Cloud computing makes use of virtualization - but cloud computing
| > | also focuses on allowing computing to be delivered as a service.
| > | http://www.accelacomm.com/jaw/sfnl/114/51521223/
| > | _______________________________________________
| > | QuantLib-dev mailing list
| > | Qua...@li...
| > | https://lists.sourceforge.net/lists/listinfo/quantlib-dev
| >
| > --
| > "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
| > dark to read." -- Groucho Marx

-- 
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx

Re: [Quantlib-dev] Google Summer of Code

[Alok <qua...@bi...>]

On Sun, Feb 19, 2012 at 11:18 PM, Dirk Eddelbuettel <ed...@de...> wrote:
>
> On 19 February 2012 at 22:58, Alok wrote:
> | So I've explored the SourceForge project page some more and found the
> | feature requests page on the tracker. And this entry by
> | Nobody/Anonymous (nobody) struck me as interesting.
> |
> | http://sourceforge.net/tracker/?func=detail&aid=1651713&group_id=12740&atid=362740
> |
> | I would appreciate it very much if someone can elaborate on what sort
> | of extension would someone be looking for. I do know that RQuantLib
> | was developed as a Summer of Code project to extend QuantLib to the
> | R-Project in 2009.
>
> I was about to comment on this (as I was the person suggesting that work and
> the mentor -- that project worked out well).

Would you be interested in mentoring for the Google Summer of Code
again? I see from the RQuantLib page
http://dirk.eddelbuettel.com/code/rquantlib.html that: "There are lots
more financial instruments covered in QuantLib. RQuantLib should grow
to accomodate these. Help in writing the R wrappers would accelerate
the provision of RQuantLib hooks for these."

How is the coverage of RQuantLib now? I am eager for an opportunity in
extending QuantLib for either R or ROOT. What is your view on this?

>
> We could possibly have people work in QL under different umbrella
> organisations too.  I know Portland St often provided a home.
>
> The real shortage may be on skilled mentors with a little bit of time. Google
> Summer of Code is a nice program, and it could fit for QuantLib Extension
> Proposals.
>
> Dirk
>
>
> | Any ideas/thoughts/advise regarding this would be much appreciated.
> |
> | best regards,
> | Alok
> |
> | On Sun, Feb 19, 2012 at 10:29 PM, Alok <qua...@bi...> wrote:
> | > Hello,
> | >
> | > Google has announced its Summer of Code again for this year
> | > http://www.google-melange.com/gsoc/homepage/google/gsoc2012 . And I
> | > was wondering if there are any ideas for QuantLib projects for this
> | > program. I would love to hear from prospective mentors about
> | > challenges that an experienced C++ developer can contribute towards
> | > this effort for 2-3 months over the summer. Please do respond even if
> | > you don't have the time to participate in the program. I'll collect
> | > ideas from the responses and post it onto a handy wiki page for later
> | > use.
> | >
> | > p.s. I notice that there is a nice GitHub QuantLib repository at
> | > https://github.com/lballabio/quantlib/commits/master I wonder how far
> | > behind or incomplete it is from the project svn repository at
> | > https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
> | > checkout from svn trunk clocked at 573MB. And I guess that with a few
> | > more MBs I might as well get the whole project history offline from
> | > GitHub instead of running expensive svn checkouts.
> | >
> | > best regards,
> | > Alok
> |
> | ------------------------------------------------------------------------------
> | Virtualization & Cloud Management Using Capacity Planning
> | Cloud computing makes use of virtualization - but cloud computing
> | also focuses on allowing computing to be delivered as a service.
> | http://www.accelacomm.com/jaw/sfnl/114/51521223/
> | _______________________________________________
> | QuantLib-dev mailing list
> | Qua...@li...
> | https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> --
> "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
> dark to read." -- Groucho Marx

Re: [Quantlib-dev] Google Summer of Code

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

On 19 February 2012 at 22:58, Alok wrote:
| So I've explored the SourceForge project page some more and found the
| feature requests page on the tracker. And this entry by
| Nobody/Anonymous (nobody) struck me as interesting.
| 
| http://sourceforge.net/tracker/?func=detail&aid=1651713&group_id=12740&atid=362740
| 
| I would appreciate it very much if someone can elaborate on what sort
| of extension would someone be looking for. I do know that RQuantLib
| was developed as a Summer of Code project to extend QuantLib to the
| R-Project in 2009.

I was about to comment on this (as I was the person suggesting that work and
the mentor -- that project worked out well).  

We could possibly have people work in QL under different umbrella
organisations too.  I know Portland St often provided a home.

The real shortage may be on skilled mentors with a little bit of time. Google
Summer of Code is a nice program, and it could fit for QuantLib Extension
Proposals.

Dirk

 
| Any ideas/thoughts/advise regarding this would be much appreciated.
| 
| best regards,
| Alok
| 
| On Sun, Feb 19, 2012 at 10:29 PM, Alok <qua...@bi...> wrote:
| > Hello,
| >
| > Google has announced its Summer of Code again for this year
| > http://www.google-melange.com/gsoc/homepage/google/gsoc2012 . And I
| > was wondering if there are any ideas for QuantLib projects for this
| > program. I would love to hear from prospective mentors about
| > challenges that an experienced C++ developer can contribute towards
| > this effort for 2-3 months over the summer. Please do respond even if
| > you don't have the time to participate in the program. I'll collect
| > ideas from the responses and post it onto a handy wiki page for later
| > use.
| >
| > p.s. I notice that there is a nice GitHub QuantLib repository at
| > https://github.com/lballabio/quantlib/commits/master I wonder how far
| > behind or incomplete it is from the project svn repository at
| > https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
| > checkout from svn trunk clocked at 573MB. And I guess that with a few
| > more MBs I might as well get the whole project history offline from
| > GitHub instead of running expensive svn checkouts.
| >
| > best regards,
| > Alok
| 
| ------------------------------------------------------------------------------
| Virtualization & Cloud Management Using Capacity Planning
| Cloud computing makes use of virtualization - but cloud computing 
| also focuses on allowing computing to be delivered as a service.
| http://www.accelacomm.com/jaw/sfnl/114/51521223/
| _______________________________________________
| QuantLib-dev mailing list
| Qua...@li...
| https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx

Re: [Quantlib-dev] Google Summer of Code

[Alok <qua...@bi...>]

So I've explored the SourceForge project page some more and found the
feature requests page on the tracker. And this entry by
Nobody/Anonymous (nobody) struck me as interesting.

http://sourceforge.net/tracker/?func=detail&aid=1651713&group_id=12740&atid=362740

I would appreciate it very much if someone can elaborate on what sort
of extension would someone be looking for. I do know that RQuantLib
was developed as a Summer of Code project to extend QuantLib to the
R-Project in 2009.

Any ideas/thoughts/advise regarding this would be much appreciated.

best regards,
Alok

On Sun, Feb 19, 2012 at 10:29 PM, Alok <qua...@bi...> wrote:
> Hello,
>
> Google has announced its Summer of Code again for this year
> http://www.google-melange.com/gsoc/homepage/google/gsoc2012 . And I
> was wondering if there are any ideas for QuantLib projects for this
> program. I would love to hear from prospective mentors about
> challenges that an experienced C++ developer can contribute towards
> this effort for 2-3 months over the summer. Please do respond even if
> you don't have the time to participate in the program. I'll collect
> ideas from the responses and post it onto a handy wiki page for later
> use.
>
> p.s. I notice that there is a nice GitHub QuantLib repository at
> https://github.com/lballabio/quantlib/commits/master I wonder how far
> behind or incomplete it is from the project svn repository at
> https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
> checkout from svn trunk clocked at 573MB. And I guess that with a few
> more MBs I might as well get the whole project history offline from
> GitHub instead of running expensive svn checkouts.
>
> best regards,
> Alok

[Quantlib-dev] Google Summer of Code

[Alok <qua...@bi...>]

Hello,

Google has announced its Summer of Code again for this year
http://www.google-melange.com/gsoc/homepage/google/gsoc2012 . And I
was wondering if there are any ideas for QuantLib projects for this
program. I would love to hear from prospective mentors about
challenges that an experienced C++ developer can contribute towards
this effort for 2-3 months over the summer. Please do respond even if
you don't have the time to participate in the program. I'll collect
ideas from the responses and post it onto a handy wiki page for later
use.

p.s. I notice that there is a nice GitHub QuantLib repository at
https://github.com/lballabio/quantlib/commits/master I wonder how far
behind or incomplete it is from the project svn repository at
https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk. The
checkout from svn trunk clocked at 573MB. And I guess that with a few
more MBs I might as well get the whole project history offline from
GitHub instead of running expensive svn checkouts.

best regards,
Alok

[Quantlib-dev] Will Quantlib Attend Google Summer of Code?

[x. <xia...@qq...>]

Hi, will Quantlib Attend this year's Google Summer of Code?

http://www.google-melange.com/gsoc/events/google/gsoc2012

[Quantlib-dev] 1.2 freeze

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

Hi all,
    if there's no big problems to be addressed, I'd go into code
freeze on the 1.2 branch to finalize the release.
If you have to commit anything in the QuantLib or QuantLib-SWIG
modules, please drop me a line first.

Luigi

Re: [Quantlib-dev] test suite link error

[cf16 <cf1...@gm...>]

yes, it was it. I have added "existing item" to QuantLib project in
QuantLib_vc10 and it is OK now.
thank you very, very much.

Piotr
-- 
View this message in context: http://old.nabble.com/test-suite-link-error-tp33282311p33289908.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] test suite link error

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

On Wed, Feb 8, 2012 at 10:27 PM, cf16 <cf1...@gm...> wrote:
> yes, these files are present in ql/math/randomnumbers/

I mean in the VC project.  Do you see them from Visual Studio when you
open the solution? They should be under the "QuantLib" project under
math/randomnumbers.

Luigi

Re: [Quantlib-dev] test suite link error

[cf16 <cf1...@gm...>]

yes, these files are present in ql/math/randomnumbers/ 
-- 
View this message in context: http://old.nabble.com/test-suite-link-error-tp33282311p33289385.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] test suite link error

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

If you're using a checkout from Subversion, there's the chance that
the VC10 project is not updated.  Check if
<ql/math/randomnumbers/sobolbrownianbridgersg.cpp> is in the project,
and if not, add it.

Luigi


On Wed, Feb 8, 2012 at 1:51 AM, cf16 <cf1...@gm...> wrote:
>
> hi all,
> so at the beginning I was not able to build test suiteat all, but after
> rebuild boost by running bootstrap libboost_unit_test_framework lib has been
> created, but... now I get this linker error:
>
> InitializeBuildStatus:
>  Touching ".\build\vc100\Win32\Debug\testsuite.unsuccessfulbuild".
> ClCompile:
>  All outputs are up-to-date.
> Link:
>     Creating library bin\QuantLib-test-suite-vc100-mt-gd.lib and object
> bin\QuantLib-test-suite-vc100-mt-gd.exp
> hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
> "public: __thiscall
> QuantLib::SobolBrownianBridgeRsg::SobolBrownianBridgeRsg(unsigned
> int,unsigned int,enum QuantLib::SobolBrownianGenerator::Ordering,unsigned
> long,enum QuantLib::SobolRsg::DirectionIntegers)"
> (??0SobolBrownianBridgeRsg@QuantLib@@QAE@IIW4Ordering@SobolBrownianGenerator@1@KW4DirectionIntegers@SobolRsg@1@@Z)
> referenced in function "public: static void __cdecl
> HybridHestonHullWhiteProcessTest::testZeroBondPricing(void)"
> (?testZeroBondPricing@HybridHestonHullWhiteProcessTest@@SAXXZ)
> hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
> "public: unsigned int __thiscall
> QuantLib::SobolBrownianBridgeRsg::dimension(void)const "
> (?dimension@SobolBrownianBridgeRsg@QuantLib@@QBEIXZ) referenced in function
> "public: __thiscall QuantLib::MultiPathGenerator<class
> QuantLib::SobolBrownianBridgeRsg>::MultiPathGenerator<class
> QuantLib::SobolBrownianBridgeRsg>(class boost::shared_ptr<class
> QuantLib::StochasticProcess> const &,class QuantLib::TimeGrid const &,class
> QuantLib::SobolBrownianBridgeRsg,bool)"
> (??0?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@QAE@ABV?$shared_ptr@VStochasticProcess@QuantLib@@@boost@@ABVTimeGrid@1@VSobolBrownianBridgeRsg@1@_N@Z)
> hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
> "public: struct QuantLib::Sample<class std::vector<double,class
> std::allocator<double> > > const & __thiscall
> QuantLib::SobolBrownianBridgeRsg::nextSequence(void)const "
> (?nextSequence@SobolBrownianBridgeRsg@QuantLib@@QBEABU?$Sample@V?$vector@NV?$allocator@N@std@@@std@@@2@XZ)
> referenced in function "private: struct QuantLib::Sample<class
> QuantLib::MultiPath> const & __thiscall QuantLib::MultiPathGenerator<class
> QuantLib::SobolBrownianBridgeRsg>::next(bool)const "
> (?next@?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@ABEABU?$Sample@VMultiPath@QuantLib@@@2@_N@Z)
> hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
> "public: struct QuantLib::Sample<class std::vector<double,class
> std::allocator<double> > > const & __thiscall
> QuantLib::SobolBrownianBridgeRsg::lastSequence(void)const "
> (?lastSequence@SobolBrownianBridgeRsg@QuantLib@@QBEABU?$Sample@V?$vector@NV?$allocator@N@std@@@std@@@2@XZ)
> referenced in function "private: struct QuantLib::Sample<class
> QuantLib::MultiPath> const & __thiscall QuantLib::MultiPathGenerator<class
> QuantLib::SobolBrownianBridgeRsg>::next(bool)const "
> (?next@?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@ABEABU?$Sample@VMultiPath@QuantLib@@@2@_N@Z)
> bin\QuantLib-test-suite-vc100-mt-gd.exe : fatal error LNK1120: 4 unresolved
> externals
>
> Build FAILED.
>
> Time Elapsed 00:07:23.45
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
>
> /////////////////
>
> moreover, I'm building QuantLib_vc10.sln and every project is beeing created
> with success, just this test suite becouse of Sobol. I have checked that
> SobolBrownianBridgeRsg takes different parameters indeed in constructor, but
> I think it'snot it as it was certainly investigated.
> I use QuantLib on a regular basis - there have never been any problems that
> some externals is unresolved, why this hybridhestonhullwhiteprocess.obj ?
> please help.
>

[Quantlib-dev] test suite link error

[cf16 <cf1...@gm...>]

hi all,
so at the beginning I was not able to build test suiteat all, but after
rebuild boost by running bootstrap libboost_unit_test_framework lib has been
created, but... now I get this linker error:
 
InitializeBuildStatus:
  Touching ".\build\vc100\Win32\Debug\testsuite.unsuccessfulbuild".
ClCompile:
  All outputs are up-to-date.
Link:
     Creating library bin\QuantLib-test-suite-vc100-mt-gd.lib and object
bin\QuantLib-test-suite-vc100-mt-gd.exp
hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
"public: __thiscall
QuantLib::SobolBrownianBridgeRsg::SobolBrownianBridgeRsg(unsigned
int,unsigned int,enum QuantLib::SobolBrownianGenerator::Ordering,unsigned
long,enum QuantLib::SobolRsg::DirectionIntegers)"
(??0SobolBrownianBridgeRsg@QuantLib@@QAE@IIW4Ordering@SobolBrownianGenerator@1@KW4DirectionIntegers@SobolRsg@1@@Z)
referenced in function "public: static void __cdecl
HybridHestonHullWhiteProcessTest::testZeroBondPricing(void)"
(?testZeroBondPricing@HybridHestonHullWhiteProcessTest@@SAXXZ)
hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
"public: unsigned int __thiscall
QuantLib::SobolBrownianBridgeRsg::dimension(void)const "
(?dimension@SobolBrownianBridgeRsg@QuantLib@@QBEIXZ) referenced in function
"public: __thiscall QuantLib::MultiPathGenerator<class
QuantLib::SobolBrownianBridgeRsg>::MultiPathGenerator<class
QuantLib::SobolBrownianBridgeRsg>(class boost::shared_ptr<class
QuantLib::StochasticProcess> const &,class QuantLib::TimeGrid const &,class
QuantLib::SobolBrownianBridgeRsg,bool)"
(??0?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@QAE@ABV?$shared_ptr@VStochasticProcess@QuantLib@@@boost@@ABVTimeGrid@1@VSobolBrownianBridgeRsg@1@_N@Z)
hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
"public: struct QuantLib::Sample<class std::vector<double,class
std::allocator<double> > > const & __thiscall
QuantLib::SobolBrownianBridgeRsg::nextSequence(void)const "
(?nextSequence@SobolBrownianBridgeRsg@QuantLib@@QBEABU?$Sample@V?$vector@NV?$allocator@N@std@@@std@@@2@XZ)
referenced in function "private: struct QuantLib::Sample<class
QuantLib::MultiPath> const & __thiscall QuantLib::MultiPathGenerator<class
QuantLib::SobolBrownianBridgeRsg>::next(bool)const "
(?next@?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@ABEABU?$Sample@VMultiPath@QuantLib@@@2@_N@Z)
hybridhestonhullwhiteprocess.obj : error LNK2019: unresolved external symbol
"public: struct QuantLib::Sample<class std::vector<double,class
std::allocator<double> > > const & __thiscall
QuantLib::SobolBrownianBridgeRsg::lastSequence(void)const "
(?lastSequence@SobolBrownianBridgeRsg@QuantLib@@QBEABU?$Sample@V?$vector@NV?$allocator@N@std@@@std@@@2@XZ)
referenced in function "private: struct QuantLib::Sample<class
QuantLib::MultiPath> const & __thiscall QuantLib::MultiPathGenerator<class
QuantLib::SobolBrownianBridgeRsg>::next(bool)const "
(?next@?$MultiPathGenerator@VSobolBrownianBridgeRsg@QuantLib@@@QuantLib@@ABEABU?$Sample@VMultiPath@QuantLib@@@2@_N@Z)
bin\QuantLib-test-suite-vc100-mt-gd.exe : fatal error LNK1120: 4 unresolved
externals

Build FAILED.

Time Elapsed 00:07:23.45
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

/////////////////

moreover, I'm building QuantLib_vc10.sln and every project is beeing created
with success, just this test suite becouse of Sobol. I have checked that
SobolBrownianBridgeRsg takes different parameters indeed in constructor, but
I think it'snot it as it was certainly investigated.
I use QuantLib on a regular basis - there have never been any problems that
some externals is unresolved, why this hybridhestonhullwhiteprocess.obj ?
please help.
-- 
View this message in context: http://old.nabble.com/test-suite-link-error-tp33282311p33282311.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Is this design ok?

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

Hi Luigi,

thank you for your answer. The test suite runs fine with both changes.

The order in which update1() and update2() are called is in fact 
crucial. The model is a markov functional one factor model. update1() 
precomputes arbitrage free smiles from a given volatility structure. 
update2() bootstraps a numeraire surface fitting these smiles. So 
update1() only depends on the market data input, while update2() in 
addition depends on the model parameters, i.e. the parameters describing 
the driving state process.

I would apreciate to have both changes in the code, if no one has second 
thoughts.

Thanks again,
Peter


Am 07.02.2012 14:59, schrieb Luigi Ballabio:
> Hi Peter,
>      apologies for the delay.
>
>> 1. Why is CalibratedModel derived from Observer as "public" and not
>> "public virtual" ?
> It's probably an oversight.  Try changing it and running the test
> suite; if it works, give me a shout and I'll correct it.
>
>> 2. Why is update() and not generateArguments(); notifyObservers();
>> called in CalibratedModel::setParams() ?
> It might just be that whoever wrote the call didn't think that
> update() could be extended.
> On the other hand, it's been a while since I looked at that part of
> the library, and I'm not sure that one wouldn't want the model to
> update fully when parameters are set... Hmm. Again, you might try to
> make the change and see what happens.
>
> Another possibility is that you decouple the two updates entirely.
> You might call update2 code from the model's update() method, and
> manage update1() by using another observer. Something like:
>
> class YourModel {
>    private:
>      class updateHelper : public Observer {
>        public:
>          updateHelper(YourModel* model) : model(model) {}
>          void update() { model->update1(); }
>      };
>      ...
>      updateHelper uh;
>    public:
>      YourModel(whatever) : uh(this) {
>          this->registerWith(a);  // triggers update2()
>          this->registerWith(b);  // triggers update2()...
>          uh->registerWith(b);   // ...and also update1()
>      }
> };
>
> The problem is, it's not guaranteed in what order update1() and
> update2() will be called, which might be a showstopper for you.
>
> In any case, let me know how it goes.
>
> Later,
>      Luigi
>
>
> On Sun, Jan 29, 2012 at 6:09 PM, Peter Caspers<pca...@vo...>  wrote:
>> Hello Luigi,
>>
>> I want to add a new model to the lib. The model observes a yield term
>> structure and a volatility structure. Whenever one of them changes a
>> method update1() shall be called. Furthermore the model has a (piecewise
>> constant) parameter that can be calibrated to additional instruments.
>> When this parameter changes, another method update2() should be called.
>> In fact, update1() calls update2(). Both methods update1() and update2()
>> need some computation time, so in particular during calibration
>> update1() should _not_ be called. Finally, the model should be a
>> LazyObject, because multiple changes in market data (say a parallel
>> shift in the volatility surface) should trigger only one call of update1().
>>
>> I think I have a solution, but I want to learn a bit about the libs
>> design and I want to be sure to be in line with this design and not have
>> overseen something. So could you please have a look?
>>
>> My first attempt was the following: Let the model inherit from
>> TermstructureConsistentModel, CalibratedModel and LazyObject. However,
>> when calling registerWith(myYts's), this registration is ambiguous
>> because both LazyObject and CalibratedModel derive from Observer, but in
>> the case of CalibratedModel this is no virtual inheritance. So my first
>> question would be: Is there a special reason for that or could the
>> declaration also be CalibratedModel : public virtual Observer, ... ?
>> Given I would change that, I need to overwrite the update() method in my
>> model then basically calling LazyObject::update(). The
>> performCalculations() implementation in my model would call update1()
>> and update2().
>>
>> The next problem occurs in the setParams() method of CalibratedModel
>> which calls update() at the end, causing full recalculation (i.e. calls
>> of update1() and update2()) of the model, which I wanted to avoid. My
>> interpretation of the purpose of generateArguments() up to now was to
>> update the model w.r.t. changes in its parameters. So a call of
>> generateArguments() and notifyObservers() instead of update() in the
>> setParams() method would be enough (and produce the desired behaviour in
>> my case). The implementation of generateArguments() in my model would
>> then simply call update2(). In fact, a call of setParams() would
>> instantaneously trigger a call of update2(), which would not be
>> consistent with the lazy behaviour of the model w.r.t. market data
>> changes, but this is no serious problem I guess.
>>
>> Summarizing my questions:
>>
>> 1. Why is CalibratedModel derived from Observer as "public" and not
>> "public virtual" ?
>> 2. Why is update() and not generateArguments(); notifyObservers();
>> called in CalibratedModel::setParams() ?
>>
>> The solution I actually arrived at (requiring no adjustments in the lib)
>> is the following:
>>
>> - Use LazyObject::registerWith(myYts's), i.e. only let the Observer of
>> LazyObject observe the term structures and not the observers copy in
>> CalibratedModel.
>> - Do not implement an update() method in my model.
>> - Implement performCalculations() and generateArguments() just as
>> described above.
>>
>> Is this latter way correct ?
>>
>> Thanks a lot
>> Peter
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Looping dependencies

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

Hi Luca


On Sun, Feb 5, 2012 at 9:26 PM, Luca Billi <luc...@gm...> wrote:
> I noticed that the current implementation of LazyObjects generates
> infinite recursions
> in the case the dependency hierarchy among Observer/Observable objects
> contains loops.
>
> A suggestion to break the infinite recursion is to replace the update()
> method as follows:
> [...]

good catch, even if on the 1.2.0 release branch it was already fixed as in
the following

   inline void LazyObject::update() {
       // forwards notifications only the first time
       if (calculated_) {
           // set to false early, otherways non-lazy observers would be
           // served obsolete data because of calculated_ being still true
           calculated_ = false;
           // observers don't expect notifications from frozen objects
           if (!frozen_)
               notifyObservers();
       }
   }


I've added your "prevent infinite recursion" comment too

ciao -- Nando