I'm looking for a vector/matrix library that is suitable for relatively simple vector maths (+-*/, x=Ax+By) with occasional use of matrices (simple covariance calcs, matrix inversion). My main concerns are being able to optimise for speed by being able to capitalise on vendor-tuned libs on a specific architecture(e.g. MKL, ATLAS ) and maintain portability across a wide range of platforms. I'm looking to support vectors and matrices of types float, double, complex<float> and complex<double>. uBLAS seems to support specification of a storage format that allows me to define/assume an underlying representation of contiguous floats/doubles (with stride info) suitable for typical C-optimised signal processing functions to be applied. (No doubt I will hide the signal processing functions behind an appropriate lightweight interface, but it is important to be able to avoid copies etc and get to hand-tuned FFTs etc that typically are only supplied for C interfaces.) Is uBLAS the right tool for the job? (http://itpp.sourceforge.net provides an idea of where I'd like to see a processing layer end up albeit it is GPL (commercial use a problem) and doesn't have a clear separation between the underlying matrix/vectors and the various types of processing functions) Some other questions and observations: 1) What is the state of the bindings aspect of uBLAS with Atlas et al (or is this a separate project that hasn't got quite the same impetus to it as the main uBLAS development.) 2) Is there any implementation of 'tiny' vectors and matrices that reduces the abstraction penalty of say 3x3 or say 8 element vectors when compared with C. Is this possible/desirable while maintaining the uBLAS interface? 3) At the moment from a users point of view I feel the ublas docs focus heavily on implementation detail and I haven't managed to find too much in the way of simple tutorial information (pointers appreciated) to encourage simplified usage. If uBLAS is the right way forward for me I would be happy to contribute to this documentation effort. (There is mention of newer post 1.32 docs - is this already being addressed?)