Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

September 24th, 2014, 12:26 pm

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.
Last edited by Cuchulainn on September 23rd, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
lballabio
Posts: 0
Joined: January 19th, 2004, 12:34 pm

Learning Quantlib

September 25th, 2014, 8:47 am

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.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

September 25th, 2014, 11:49 am

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?
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

September 26th, 2014, 9:17 am

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.
Last edited by Cuchulainn on September 25th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
lballabio
Posts: 0
Joined: January 19th, 2004, 12:34 pm

Learning Quantlib

September 29th, 2014, 9:08 am

Yes, it would work.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

September 29th, 2014, 11:50 am

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?
Last edited by Cuchulainn on September 28th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
lballabio
Posts: 0
Joined: January 19th, 2004, 12:34 pm

Learning Quantlib

October 1st, 2014, 12:50 pm

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.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

October 10th, 2014, 6:01 am

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
Last edited by Cuchulainn on October 9th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
pcaspers
Posts: 30
Joined: June 6th, 2005, 9:49 am
Location: Germany

Learning Quantlib

October 10th, 2014, 6:57 am

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.
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

October 10th, 2014, 7:40 am

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#..
Last edited by Cuchulainn on October 9th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
pcaspers
Posts: 30
Joined: June 6th, 2005, 9:49 am
Location: Germany

Learning Quantlib

October 10th, 2014, 8:46 am

did you have a look here ?it is under ql / patterns / observable.hpp / cpp
 
User avatar
Cuchulainn
Posts: 20250
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Learning Quantlib

October 10th, 2014, 9:44 am

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.
Last edited by Cuchulainn on October 9th, 2014, 10:00 pm, edited 1 time in total.
 
User avatar
pcaspers
Posts: 30
Joined: June 6th, 2005, 9:49 am
Location: Germany

Learning Quantlib

October 10th, 2014, 10:24 am

alright, sorry, I didn't follow the discussion really