I have been reading about the development of qfcl with interest. My background is numerical computing for estimation and signal processing (non-finance), and I hope to help out with the numerics side of this library.Before too much work is done with the numerical algorithms in the generic library portion, I feel like there needs to be a formal discusion on the matrix datatype. There has been a little discusion on this topic, but without firm talking points or a final consensus.I have gathered together what I feel are the pros and cons of various implementations. I am going to make each library a separate post in this threat. My list is not exhaustive, so feel free to add other libraries or any custom implementation.

Boost 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 - 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 - 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.

Boost Multiarray - http://www.boost.org/doc/libs/1_47_0/li ... index.html Pro - Standard boost library Pro - Handles large number of dimensions Pro - Allows indicing/slicing of dimensions Pro - Boost software license Pro - Can specify column, row major, or custom storage Con - Fairly limited documentation Con - Does not allow for linear iteration of elements Con - Does not provide any mathematical operations Con - Requires bindings library (not reviewed boost) for BLAS/LAPACK Con - No active development, only maintenance

Armadillo - http://arma.sourceforge.net/ Pro - Actively developed Pro - Simple syntax (similar to MATLAB and Octave) Pro - Uses expression templates for delayed evaluation Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Pro - Implements 1-D, 2-D, and 3-D data structures Pro - Can easily use externally managed memory Pro - Can use matrices with compile-type sizes Con - Only a few most common dense matrices are implemented Con - No sparse matrices Con - Not much documentation Con - Not as popular as other libraries Con - Column major storage only Con - LGPL software license Not sure how hard it is to expand Should be extensible to automatic differentiation I prefer this library or Eigen to the other possibilities I have found.

Eigen - http://eigen.tuxfamily.org/index.php?title=Main_Page Pro - Actively developed Pro - Simple syntax Pro - Handles common matrix structures including sparse Pro - Contains a set of unofficial modules for FFT, nonlinear equations, etc Pro - Uses expression templates for delayed evaluation Pro - Explicit vectorization using SSE and other instruction sets Pro - Can use matrices with compile-type sizes Pro - Extensively tested Pro - Designed for extensibility Pro - Example shows how to use automatic differentiation (ADOLC) Pro - Can specify column or row major storage Con - 1-D and 2-D only Con - No parallelization Con - Cannot interface with BLAS/LAPACK Con - LGPL license

MTL4 - http://www.simunova.com/de/node/24 Pro - Actively developed Pro - Simple syntax Pro - Uses expression templates for delayed evaluation Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Con - 1-D and 2-D only Con - Mostly a commercial product Con - Only a few most common dense matrices are implemented Con - Not much documentation Con - Unknown license

IT++ - http://sourceforge.net/apps/wordpress/itpp/ Pro - Actively developed Pro - Contains signal processing functions such as FFT Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Pro - Implements sparse matricies Pro - Simple syntax (similar to MATLAB and Octave) Pro - Well documented reference manual Pro - Can easily use externally managed memory Con - 1-D and 2-D only Con - Only general dense matricies (no symmetric, triangular, etc) Con - No delayed evaluation like UBLAS Con - Less focus on numerics than on communications theory Con - Fixed matrix element storage order Con - GPL software license Pre-defined small matrices up to 3x3

Blitz++ - http://www.oonumerics.org/blitz/ Pro - Simple syntax Pro - Handles large number of dimensions Pro - Allows indicing/slicing of dimensions Pro - Uses expression templates for delayed evaluation Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Pro - Can easily use externally managed memory Pro - Can use matrices with compile-type sizes Pro - Can specify column, row major, or custom storage Pro - Contains useful functions for finite difference stencils Pro - Well documented Pro - Well tested Con - Not actively developmented Con - No sparse matrices Con - May have licensing issues

NewMat - http://www.robertnz.net/nm_intro.htm Pro - Handles all major matrix structures Pro - Uses expression templates for delayed evaluation Pro - No license issues Con - Little if any active development Con - 1-D and 2-D only Con - No sparse matrices Con - Only supports float or double Con - No complex elements Con - No support for BLAS/LAPACK Con - Cannot use externally managed memory Numerical algorithms are from Numerical Recipes in C

vector<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 memory

PetSC - http://www.mcs.anl.gov/petsc/petsc-as/ Pro - Actively developed Pro - Handles all major matrix structures including sparse Pro - Can interface with other libraries Pro - Lots of linear algebra, nonlinear equations, and PDE functions Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Pro - Well documented reference manual Pro - Well tested Con - Not much of a users manual Con - Basic vector/matrix math is almost at the level of BLAS calls Con - Primilary designed for high performance computing (clusters, etc) Con - Huge library Con - Compilation on Windows is extremely difficult or impossible Pure C functional syntax

Trillinos - http://trilinos.sandia.gov Pro - Actively developed Pro - Handles all major matrix structures including sparse Pro - Can interface with other libraries Pro - Lots of linear algebra, nonlinear equations, and PDE functions Pro - Natively interfaces with BLAS/LAPACK/ATLAS/MKL/ACML Pro - Well documented reference manual Pro - Well tested Con - Not much of a users manual Con - Library subpackage names appear arbitrary Con - Primilary designed for high performance computing (clusters, etc) Con - Huge library Con - Compilation on Windows is extremely difficult or impossible

If the library offers only LGPL, it can never be used by us, right? Also, I'm curious about parallelization, what do you mean, does that mean every other matrix library that you listed support parallelization but not Eigen?QuoteOriginally posted by: OOglesbyEigen - http://eigen.tuxfamily.org/index.php?title=Main_Page Con - 1-D and 2-D only Con - No parallelization Con - Cannot interface with BLAS/LAPACK Con - LGPL license

Regarding Eigen & parallelism: in a way, it's a work in progress, and there is expectation is that the end-user will make use of coarser-grained parallelism (which largely makes sense to me, taking into account thread management overhead):http://eigen.tuxfamily.org/index.php?ti ... rtQuoteThe default is no parallelization since we expect parallelization occurs at the highest level, i.e., outside Eigen. Indeed, parallelizing the most outer loop is usually the best strategy though sometimes it might be complicated.That being said, there is some use of OpenMP:http://eigen.tuxfamily.org/index.php?title=3.0QuoteNow using OpenMP when it is enabled, parallelizing crucial code such as matrix-matrix product. Important optimizations in many places, including in matrix-matrix product which is now nearly as fast as Intel MKL and GotoBLAS, including on multi-CPU systems (see above point about OpenMP).BTW, regarding BLAS/LAPACK -- it's a feature, not a bug:http://eigen.tuxfamily.org/index.php?ti ... FLAPACK.3F

Regarding the interface requirements (and thus licensing -- see below).In my view, we should impose as-little-requirements-as-possible and thus enable the end-users to switch the libraries as needed (and thus the licensing depends on what's suitable to the user) and free us from reinventing the wheel (as the list shows, there's plenty of well-optimized open-source libraries out there).We may or may not recommend / bundle a just-want-to-try-it-out library, but I think it should be compatible with the Boost license (perhaps MIT would be fine too, for instance).At least as far as matrices are concerned, it seems that typedefing the choice and accessing via operator() could be the way to go, as operator() is supported by most of the libraries listed:- Boost.uBLAS - http://www.boost.org/doc/libs/release/l ... atrix.htm- Armadillo - http://arma.sourceforge.net/docs.html#syntax- Eigen - http://eigen.tuxfamily.org/dox-devel/Tu ... Accessors- MTL 4 - https://simunova.zih.tu-dresden.de/mtl4 ... ypes.html- IT++ - http://itpp.sourceforge.net/current/cla ... b5b36a2a8- dlib (Boost-licensed, add it to the list?) - http://dlib.net/containers.html#matrixOther 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...