Page 2 of 2

Learning Quantlib

Posted: September 24th, 2014, 12:26 pm
by Cuchulainn
QuoteOriginally posted by: lballabioWe've been talking about offloading functionality to Boost (including signal2. Observer is used everywhere, not only in MC.) I'm not sure if we can do it while keeping backward compatibility, or if we'll have to start a new branch to move towards a version 2.0.There is an intermediate solution, namely keeping the external interface the same e.g. Update() only having to change the code internals (used to do that for a living years ago) from classic GOF to stuff using callback function with Boost or std function and bind. It also means you can have a bunch of callable object types of different styles as observers. BTW this is in my Boost I C++ book.In fact .. you can use Boost signals internally without ruffling any feathers since it's all signature-based, i.e.void Some_Func_Thing(void); // in fact a contract or interface...QuoteC++11 is more tricky. It would be useful, sure, and I'm itching to try it, but I'm guessing that a lot of people are still stuck with versions of VC++ that don't support it. It's more than half in this sample, and I'm under the impression that banking IT departments are more conservative than most...Let them eat Boost (for the moment) . Seems a lot of C++ 11 comes from Boost. The migration path is clear.BTW only a few months ago I saw VC++ 6.0 for the first time since years.I an working in my C++ 2004 book 2nd edition and hope to have manuscript ready by December 2014. I have replaced/complemented most of the GOF patterns by C++ 11 approach, e.g. use std::function as Strategy, Command, Bridge, Template Method ==> no class hierarchy needed. Bingo.// What I am finding is that layering is a good way to compartmentalize code and ensure maintainability.

Learning Quantlib

Posted: September 25th, 2014, 8:47 am
by lballabio
QuoteOriginally posted by: CuchulainnSeems a lot of C++ 11 comes from Boost.Except for the language changes (lambdas, right-value references...) Those would be very nice to have.

Learning Quantlib

Posted: September 25th, 2014, 11:49 am
by Cuchulainn
QuoteOriginally posted by: lballabioQuoteOriginally posted by: CuchulainnSeems a lot of C++ 11 comes from Boost.Except for the language changes (lambdas, right-value references...) Those would be very nice to have.Lambda is useful.Is Boost.Move a good stepping stone to C++ 11?

Learning Quantlib

Posted: September 26th, 2014, 9:17 am
by Cuchulainn
Luigi,I had another look at observable.hpp again. I think it can be ported to signals2 etc. without changing the current interface.Here is a POC.

Learning Quantlib

Posted: September 29th, 2014, 9:08 am
by lballabio
Yes, it would work.

Learning Quantlib

Posted: September 29th, 2014, 11:50 am
by Cuchulainn
QuoteOriginally posted by: lballabioYes, it would work.General question: how many manhours effort do you think to port and test, assuming that such was the requirement? Including Boost Random 1.56?

Learning Quantlib

Posted: October 1st, 2014, 12:50 pm
by lballabio
Oh, I'm terrible at estimates Porting: not much. Days at most? If I'm not misunderstanding the idea, we're talking about replacing the implementation of a limited number of classes and keeping the interfaces. The existing structure would give a guide.Testing: quite a bit more. And we're dealing with the unforeseen here, so it's difficult to give an estimate. It might be worth to spend some time to write a good battery of unit tests, so that any bug we introduce could be pinpointed.

Learning Quantlib

Posted: October 10th, 2014, 6:01 am
by Cuchulainn
LuigiTechnically, it is not all too difficult to implement the changes. It's indeed more organizational and admin IMO. In particular, the main scenarios IMO are:A. Modify the internals of Observer, external interfaces remain the same.B. Same as A with extra (non-intrusive ) functionality (e.g. observer groups, scoped connections, combiners).C. Complete rewrite XOR parallel development.D. New opportunities/functionality not in current environment.In all cases you want to avoid side effects, so good a) requirements and b) unit tests for each client system of Observer are vital. Sub-projects1. New Observer2. (Client system)* upgrade3. Acceptance, testing, integrationWhat do you think?D

Learning Quantlib

Posted: October 10th, 2014, 6:57 am
by pcaspers
I think this was already done, and it workssignal2observerOne issue is that with many obsever / observable dependencies signal2 can be dramatically slower than the original implementation. This actually occured in the current test suite. The guilty code was optimized and now it is ok, but I think this is a major point to consider in user acceptance tests.

Learning Quantlib

Posted: October 10th, 2014, 7:40 am
by Cuchulainn
QuoteOriginally posted by: pcaspersI think this was already done, and it workssignal2observerOne issue is that with many obsever / observable dependencies signal2 can be dramatically slower than the original implementation. This actually occured in the current test suite. The guilty code was optimized and now it is ok, but I think this is a major point to consider in user acceptance tests.I'm confused!I had a look but was unable to find observer.cpp that uses signals2 and/or short overview. I looked under 'ql' directory but could not find it.What I did see was Observer with fine-grained locking which will be slow, for sure. IMO it is better to do coarse-grained locking. But that's a different scenario. BTW I find a thread-safe Singleton double scary. It's a potential bottleneck.Thread-safeness in signals2 is not quite the same as normal threading IMO. signals2 is thread-agnostic in this sense.?? looks like C#..

Learning Quantlib

Posted: October 10th, 2014, 8:46 am
by pcaspers
did you have a look here ?it is under ql / patterns / observable.hpp / cpp

Learning Quantlib

Posted: October 10th, 2014, 9:44 am
by Cuchulainn
Quotedid you have a look here ?it is under ql / patterns / observable.hpp / cppYes, I had seen that code. That was exactly the design I benchmarked (see my earlier post).1. The design presented is precisely _not_ my signals2 approach. We are talking about different things.2. It is clear that the code will be slow (set<> O(n log n) and (recursive) mutexes..)So, IMO QL does _not_ have a signals2 Observer. Quote..if you think you want a recursive mutex, you probably need to change your design instead .... undefined behavior ... quick-and-dirty solution.,..Anthony Williams C++ Concurrency in action page 65. A more appropriate pattern is Master WorkerBottom-up upgrade sequential Observer to a parallel one is painful IMO and is the wrong design. BTW the current design is still OOP while signals2 supports any callable object.

Learning Quantlib

Posted: October 10th, 2014, 10:24 am
by pcaspers
alright, sorry, I didn't follow the discussion really

Learning Quantlib

Posted: October 10th, 2014, 12:01 pm
by Cuchulainn
QuoteOriginally posted by: pcaspersalright, sorry, I didn't follow the discussion reallyNo problem, Peter. I am glad you gave me the link. Thanks for your help.Like in maths, it is sometimes good when a model reaches its limit .. it is an opportunity to discover a new one. In this case I would use the bespoke Master-Worker or even Producer-Consumer if you want N:M multiplicity between Subject and Observer (can easiliy be done in Boost with a synchronizing queue ==> no race conditions).Producer-Consumer

Learning Quantlib

Posted: November 26th, 2014, 3:26 pm
by Cuchulainn
Anyone going to the QL conference in Düsseldorf 4-5 December?