A C++ library for Arrays, Matrix, Vector, and classical linear algebra operations

Question

Which library do you use for N-dimensional arrays?

I use blitz++ at work and I really dislike some aspect of it. Some aspect of it are even dangerous. The need for resizing before using operator=. A(Range::all(), Range::all()) throws for an (0,0) matrix, etc. and the linear algebra operations are to be done via clapack.

I used and loved eigen. I appreciate its "all-in-header" implementations, the C++ syntactic sugar, and the presence of all the linear algebra operations I need (matrix multiplication, system resolution, cholesky...)

What are you using?

Answer 1

boost::array and also boost::MultiArray. There's also a pretty good linear algebra package in boost called uBLAS

Answer 2

There is also armadillo which I am using in some projects. From their website:

Armadillo is a C++ linear algebra library (matrix maths) aiming towards a good balance between speed and ease of use. Integer, floating point and complex numbers are supported, as well as a subset of trigonometric and statistics functions. Various matrix decompositions are provided through optional integration with LAPACK and ATLAS libraries.

A delayed evaluation approach is employed (during compile time) to combine several operations into one and reduce (or eliminate) the need for temporaries. This is accomplished through recursive templates and template meta-programming.

This library is useful if C++ has been decided as the language of choice (due to speed and/or integration capabilities), rather than another language like Matlab ® or Octave. It is distributed under a license that is useful in both open-source and commercial contexts.

Armadillo is primarily developed at NICTA (Australia), with contributions from around the world.

Answer 3

Does anyone know of a C++ lib that provides the sort of extended linear algebra functionality of APL?

Answer 4

We've used TNT successfully for a number of years. There are sufficient issues, however, that we're moving toward an internally developed solution instead. The two biggest sticking points for us are that

• The arrays are not thread safe, even for read access, because they use a non-thread safe reference count.
• The arrays cause all sorts of problems when you write const-correct code.

If those aren't a problem then they're fairly convenient for a lot of common array tasks.