Serving the Quantitative Finance Community

  • 1
  • 2
  • 3
  • 4
  • 5
  • 7
 
User avatar
OOglesby
Topic Author
Posts: 1
Joined: August 26th, 2011, 5:34 am

Choice of matrix library and interface

November 9th, 2011, 4:10 am

Regarding LGPL, the library can be used in both open source and commercial software. If the LGPL software is modified, then the modified source code must be provided.When I mentioned Eigen does not have parallelization, I was referring to the usage of multi-threated/parallel BLAS/LAPACK implementations. PetSC and Trilinios are the only libraries I am aware of that are designed for true parallelism (usually on a cluster). I am not terribly familiar with Eigen, so Polter has a much better understanding that I do.True most operations are common to any matrix implementation (+, -, (), etc). However, the function for accessing a single row, column, or sub-matrix is not as standardized. Creation of matrices of ones, zeros, or identity, or general initialization can also have different conventions. If the library provided function is available, the required code is shorter, easier to understand, and can take advantage of any vectorization the library provides. Maybe it is possible to use traits or wrapper functions that can be specialized for a given implementation.Maybe outrun or somebody else who knows more about traits, template specialization, and other generic techniques can jump in about how to handle non-standardized functions.
 
User avatar
OOglesby
Topic Author
Posts: 1
Joined: August 26th, 2011, 5:34 am

Choice of matrix library and interface

November 9th, 2011, 4:30 am

dlib - http://dlib.net Pro - Can use matrices with compile-type sizes Pro - Uses expression templates for delayed evaluation Pro - Boost software license Pro - Actively developed Pro - Simple syntax (similar to MATLAB and Octave) Pro - Many utility functions for matrices and arrays Pro - Many optimization and machine learning functions Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Con - Matrix documentation seems poor - mainly the header files Con - Cannot use externally managed memory Con - 1-D and 2-D only Con - No sparse matrices Con - Only general dense matricies (no symmetric, triangular, etc) Containers cannot be copied, only swapped.
 
User avatar
rmax
Posts: 374
Joined: December 8th, 2005, 9:31 am

Choice of matrix library and interface

November 9th, 2011, 9:00 am

Think we need to be careful of setting too formal rules. By this I mean: Ooglesby if there is a library and container that you think works after discussion on the forum, then implement a module using your choice.If it turns out the choice it not good, then we should be preapred to throw away the intial choice and refactor.(note I don't think that this is a decision to be taken lightly, but we should not shy away from the pain just because it is painful).The only issue will be if two or more people are writing code based on two different standards, but this we should be able to mitigate if you post what you want to do in the Prototype thread.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 9th, 2011, 12:55 pm

QuoteOther than std::vector<std::vector> an alternative would be to wrap a C-style array (new T[rows * cols];) with operator():http://www.parashift.com/c++-faq-lite/o ... aq-13.10// I believe Cuch is doing something like this for his books, but you'd have to ask him for the confirmation/details/license...That's indeed my approach at the moment. It works OK and is easy to use, so I plan to replace vector<vector<T>> by an embedded uBLAS matrix. For QFCL I will make it open source. I also have ported it to C#, so when you write apps in C# it can easily be ported to C++ and vice versa.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 9th, 2011, 1:10 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOther than std::vector<std::vector> an alternative would be to wrap a C-style array (new T[rows * cols];) with operator():http://www.parashift.com/c++-faq-lite/o ... aq-13.10// I believe Cuch is doing something like this for his books, but you'd have to ask him for the confirmation/details/license...That's indeed my approach at the moment. It works OK and is easy to use, so I plan to replace vector<vector<T>> by an embedded uBLAS matrix. For QFCL I will make it open source. I also have ported it to C#, so when you write apps in C# it can easily be ported to C++ and vice versa.try to turn it into a template that uses the uBlas *interface*. That way we can keep the choice of container and the algorithm orthogonal.Indeed, V2.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 9th, 2011, 5:20 pm

QuoteOriginally posted by: OOglesbyvector<vector> - STL implementation Pro - Part of STL Pro - Simple to use Pro - Element storage order does not matter Pro - No license issues Pro - Platform independent Pro - Low overhead indexing of elements Pro - vector is well documented Con - Not compatible with BLAS/LAPACK/ATLAS/MKL/ACML Con - Does not map linear memory to a multi-dimensional space Con - No delayed evaluation Con - Only general dense matricies can be done with ease Con - No sparse matrices Con - Cannot use externally managed memoryMy own NumericMatrix is based in vector<vector> internally.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 9th, 2011, 5:24 pm

QuoteOriginally posted by: OOglesbyBoost UBLAS - http://www.boost.org/doc/libs/1_47_0/li ... dex.htmPro - Standard boost libraryPro - Handles all major matrix structures including sparsePro - Uses expression templates for delayed evaluationPro - Can use matrices with compile-type sizesPro - Can specify column or row major storagePro - Designed as a reference implementation with accurate calculationPro - Well testedPro - Well documentedPro - Boost software licenseCon - Complex syntaxCon 2 - Documentation is hard to understandCon - 1-D and 2-D onlyCon - Requires bindings library (not reviewed boost) for BLAS/LAPACKCon - Cannot use externally managed memory easily (if at all)Con 5- Difficult to add new functionalityI am not really a fan of this library. Its syntax is too complex for my liking, and I don't like that I can't use BLAS/LAPACK easily.I spent quite some time studying uBLAS. The syntax is a bit unusual in places.What I particularly like is patterned matrices and views/proxies in uBLAS.On Con 5: what kind of functionality do you wish to add on to uBLAS? I think it is easy using adapters and layered software products.Thanks for the nice overview of the matrix libraries.
Last edited by Cuchulainn on November 8th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
OOglesby
Topic Author
Posts: 1
Joined: August 26th, 2011, 5:34 am

Choice of matrix library and interface

November 10th, 2011, 12:06 am

QuoteOriginally posted by: outrunLet's try to keep the choice of container orthogonal. Write generic algorithms that perform operations on matrices via a standardized interface ala the bindings/traits concept. ..so when we write a heat equation solver, we'll have dU/dT = -a dU^2/dX^2we can use a generic type M that supports operator (i,j), and use that interface do estimate dU_dT = M(i+1,j) - M(i,j) etcIf the matrix storage *doesn't* support (i,j) then we can wrap that interface on it ala a trait.So my suggestion would be:1) Use generic algorithms, re-use things like random access iterators in those algorithms to increase portability of those algorithms2) prevent to algorithms to become dependent on anything other than that STL and boost3) make it work efficiently via one/two/all of these mentioned libraries, ensure that we van use a BLAS via one of those, and try to make it at least work with uBlas so that users are not forces to install a 3rd party lib other than boostMy concern is that if some algorithms are kept completely generic, the a matrix becomes nothing more than a simple 2-D array. The more linear algebra and matrix functionality that is used, the more traits and wrapping code have to be written. Which means an increased burden on a user if they have a matrix type that is not pre-implemented.Another issue is my skill level and generic programming. I understand and can write generic code, but I am certainly not at the level required for boost-level work. Can somebody please point me to some simple yet non-trival examples of traits/proxies for adapting different interfaces so that I can become more familiar with the techniques?For now, I think I am going to only use simple indexing/math or ublas in the more complex functions. My plans are to start working on N-point finite difference algorithms for numerical derivatives.QuoteOriginally posted by: CuchulainnI spent quite some time studying uBLAS. The syntax is a bit unusual in places.On Con 5: what kind of functionality do you wish to add on to uBLAS? I think it is easy using adapters and layered software products.I was trying to add additional element-wise functions into the expression template framework for matching some of the Matlab functionality.
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

Choice of matrix library and interface

November 10th, 2011, 12:21 am

QuoteOriginally posted by: OOglesbyAnother issue is my skill level and generic programming. I understand and can write generic code, but I am certainly not at the level required for boost-level work. Can somebody please point me to some simple yet non-trival examples of traits/proxies for adapting different interfaces so that I can become more familiar with the techniques?Yes, I can! :-)I can even do better than that and point you to a great lecture series on these examples -- given below in the suggested studying order Background / prerequisites: // I'm assuming you might probably skip 1-9 if you're familiar with standard-level C++, but feel free to look at the TOC [STL Introduction lecture links] to verify that you are:Stephan T Lavavej's introductory series on the STLhttp://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Introduction-to-STL-with-Stephan-T-LavavejIf you haven't before, you might also consider watching Stepanov's talk on generic programming:Alexander Stepanov: STL and Its Design Principleshttp://www.stepanovpapers.com/stepanov-abstrac ... /stl.pdfC9 Lectures: Stephan T. Lavavej - Standard Template Library (STL), 10 of 10introduction to type traitshttp://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Standard-Template-Library-STL-10-of-10C9 Lectures: Stephan T Lavavej - Advanced STL, 2 of nimplementation strategies for various STL algorithms, employing the goodness of template meta-programming and type traitshttp://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-2-of-nC9 Lectures: Stephan T Lavavej - Advanced STL, 5 of nBoost Libraryhttp://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-5-of-nC9 Lectures: Stephan T Lavavej - Advanced STL, 6 of ndeveloping a generic mechanism for printing out STL containers:http://channel9.msdn.com/Shows/Going+De ... f-nPerhaps a good exercise along the lines of the last lecture is "developing a generic mechanism for accessing QFCL matrices"?BTW, the standard book reference is Andrei Alexandrescu (2001) "Modern C++ Design: Generic Programming and Design Patterns Applied", but just for introduction I'd give the lectures a go -- personally I think all of them were very good and helpful!
Last edited by Polter on November 9th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 10th, 2011, 7:02 am

QuoteBTW, the standard book reference is Andrei Alexandrescu (2001) "Modern C++ Design: Generic Programming and Design Patterns Applied", but just for introduction I'd give the lectures a go -- personally I think all of them were very good and helpful!Chapter 1 on policy-based design in C++ is very good. In fact, it is the realisation of system decomposition, provides and requires interfaces idea. So, we are converging to the same results eventually.Moving up one level, the 'language' now consist of words like component, interface, connections. Having designed them, you can then map them to C++ concepts, C# delegates or other ways.
Last edited by Cuchulainn on November 9th, 2011, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Choice of matrix library and interface

November 12th, 2011, 1:41 pm

Will there be support for compile time/tiny vectors+matrices on the lines of?
Last edited by Cuchulainn on November 11th, 2011, 11:00 pm, edited 1 time in total.