Serving the Quantitative Finance Community

 
User avatar
fancidev
Posts: 0
Joined: October 10th, 2011, 10:15 pm

Version 0.0: Prototype

November 11th, 2011, 10:36 pm

Totally agree with you. That is perhaps one of the reason why we choose to create a new library instead of extending QuantLib - the latter is too tightly coupled.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Version 0.0: Prototype

November 12th, 2011, 10:16 am

Quotefor me an imported design principle is orthogonality and independence between sub libraries. That results into separation of containers and algorithms, that's way I weight so much importance of not locking in to specific containersAt application level, developers want to work with specific containers (e.g. vectors and matrices). So, the dividing line must be very clear to users. We should provide predefined (and default) containers.
Last edited by Cuchulainn on November 11th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Version 0.0: Prototype

November 12th, 2011, 10:50 am

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuotefor me an imported design principle is orthogonality and independence between sub libraries. That results into separation of containers and algorithms, that's way I weight so much importance of not locking in to specific containersAt application level, developers want to work with specific containers (e.g. vectors and matrices). So, the dividing line must be very clear to users. We should provide predefined (and default) containers.Very true!I would suggest* minimizing taking ownership of containers behind the interfaces* let users provide them* support the standard C++STL and boost containers (without forcing a choice between them to the user).I will myself have time to support uBLAS matrices and my own NumericMatrix (contains embedded vector<vector>>).Any experience with Boost mutiarray (for 3d PDE)?
Last edited by Cuchulainn on November 11th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Version 0.0: Prototype

November 12th, 2011, 11:47 am

QuoteOriginally posted by: outrunbtw this mechanism also allows us to tweak the interface *inside out algorithm*, e.g. some authors might like a "base 1" interface instead of "base 0" . We just add a policy type to bindings, and set if default to either 0 or 1, like this. Here are two version of the diagonal_sum algorithm, one using base 0, the other base 1, both using the same generic, externally provided, container.This is an essential requirement, indeed.
 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Version 0.0: Prototype

November 28th, 2011, 9:05 am

I have seen various elements of code being posted to the forum which is good. Are we in a position to formulate the first kernel and begin to look at how it interacts?
 
User avatar
rmax
Topic Author
Posts: 374
Joined: December 8th, 2005, 9:31 am

Version 0.0: Prototype

November 28th, 2011, 10:57 am

Agreed. Are we happy with the structure of the Sandbox so that it makes sense for docs etc?
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Version 0.0: Prototype

November 28th, 2011, 8:06 pm

QuoteOriginally posted by: rmaxI have seen various elements of code being posted to the forum which is good. Are we in a position to formulate the first kernel and begin to look at how it interacts?The CGM and Cholesky subroutines based on uBLAS are ready for testing and feedback (Numerical Algebra Foundation Library).As is the Propagator pattern based in std::function and boost::signals which should replace GOF Observer. Code already posted. This could be in Architecture.Working on FDM docs.Here are the claims and feedback welcome* Features of this solution vs GOF Observer1. Non-intrusive and no inheritance needed2. Observers implement a signature, not rigid Update()3. No virtual functions4. Observers can be 'any' function (global, member, lambda, function object); it is possible to reuse existing GOF Observer code by boost::bind5. Objects be both observables and observers(this is thus the Propagator pattern)6. No multiple inheritance needed7. Use of "template template parameter" mechanism to use a different container from list<T>8. Return type is generic and not just void (but we might need 2 versions..)9. Arbitary data types supported (e.g. matrices, algorithmsa, other embedded patterns)10. Other signatures possible (generic)11. Dynamic registration/unregistration of observers12. Boost libraries and C++ 1113. Loose coupling between components; configuable; add and delete observers at run-time.*/
Last edited by Cuchulainn on November 27th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
RamneekHanda
Posts: 0
Joined: September 19th, 2010, 11:52 am

Version 0.0: Prototype

December 8th, 2011, 2:29 pm

hi guys.. do we have anything checked in that i can look at and contribute to?
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Version 0.0: Prototype

December 8th, 2011, 3:48 pm

Yes, courses. The kids have to eat. But am on schedule for:1. FDM design doc (finished)2. FDM framework V1(OO approach; outrun and Polter and all welcome can port it to generic model)3. BTW I will include the full CIR model (see Numerics thread on CIR)4. Generic MC engine Boost function and slot 60% ready. That's why I am avoiding OT at the moment.So, I can deliver now but want to make it usable and I would like peopel to contribute.outrun,6 weeks means no matrix classes from you?
Last edited by Cuchulainn on December 7th, 2011, 11:00 pm, edited 1 time in total.