Page 3 of 4

Version 0.0: Prototype

Posted: November 11th, 2011, 10:36 pm
by fancidev
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.

Version 0.0: Prototype

Posted: November 12th, 2011, 10:16 am
by Cuchulainn
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.

Version 0.0: Prototype

Posted: November 12th, 2011, 10:50 am
by Cuchulainn
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)?

Version 0.0: Prototype

Posted: November 12th, 2011, 11:47 am
by Cuchulainn
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.

Version 0.0: Prototype

Posted: November 28th, 2011, 9:05 am
by rmax
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?

Version 0.0: Prototype

Posted: November 28th, 2011, 10:57 am
by rmax
Agreed. Are we happy with the structure of the Sandbox so that it makes sense for docs etc?

Version 0.0: Prototype

Posted: November 28th, 2011, 8:06 pm
by Cuchulainn
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.*/

Version 0.0: Prototype

Posted: December 8th, 2011, 2:29 pm
by RamneekHanda
hi guys.. do we have anything checked in that i can look at and contribute to?

Version 0.0: Prototype

Posted: December 8th, 2011, 3:48 pm
by Cuchulainn
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?