Presentation of the library

        There already exist quite a few matrix packages over the internet, like Blitz++ and the Matrix Template Library, to mention only 2. So, what? Yet another matrix package? Why should I bother...

        Because there was a need for handling huge matrices, and all the other packages I found are optimized for speed, not memory.
        Because there was a need for functions like Singular Value Decomposition, that are implemented in LAPACK.
        Because I needed some very simple code, just to fit my needs. By simple, I mean not a code you have to read pages of documentation before using it (Really! Go and check the examples now if you didn't do it first thing!). No template, to begin with, Matrix is ready to use. And also a syntax I think is 'natural': no stencil, no Range2D or whatever class for matrix extraction, no Array<arg, arg, arg...> unterminable lists of adjustable features, etc... Most of those user-specified parameters aren't used in practice anyway, so I prefered to implement the ones that really are in the most straightforward way I found.
        And because no other package was satisfying enough for what I need. Not that I claim this one is perfect, its usefulness depends on what you want to do with it. But at least it combines easy to use matrix manipulation, transparent swaping using mmap and reference counting for low memory usage, and the possibility to use the power of LAPACK in the background.

What you'll find:

• A Matrix (and Vector) class in its own namespace, with the corresponding C++ facilities (operators, overload of 'math.h' functions that work on Matrices, I/O streaming...) but not so excessive as to bloat the code or the compiler. And as a dynamic library. Two of its strong points are reference counting, and the ability to dump the data in a file and load it only partially in memory, transparently.
• C++ wrappers for LAPACK functions: inverse using LU, eigenvalues/vectors, singular values/vectors, and least square estimation. Please send them if you write more wrappers (it's really easy), as I wrote only those I need.
• Utilities that you would miss if you have an Octave/Matlab(r)/Scilab background. Those include functions like eye, mean, randn, and the range generator (-1:2:5), for example.
• A plug-in framework for optimizers and models. Writing your model and calling an optimizer on it (or the other way around!) takes just a few lines, seeing the corresponding examples should convince you.
• Documentation and examples.

What you won't find:

• Speed optimized functions. I did that whenever possible, but this package assumes your main goal is to work on big matrices, or with LAPACK, or using coordinate transforms (transpose, sub-matrix extraction, flip row/column...) in which case the speed is there. It is perfectly possible to work on small matrices and do arithmetic on them, and the performances are even fair enough, but just don't hope to write a powerful 3D engine out of it.
• Generic matrices using templates, or custom storage types. Use Blitz++ if you want that. This package has been kept simple on purpose to provide what's needed and no more, in a straightforward way.
• A working LAPACK with only 10 bytes of memory. Short of rewriting it, LAPACK needs the full matrix loaded. The deal is that with this package you can use simultaneously many matrices, totalling much more memory than you have, and transparently load only what's required. The reference counting also helps, by reusing the data that is in memory without actually copying it.

What could be done to improve this package (feel free to contribute!):

• A library of commonly used scientific functions. The very basic, like mean and standard deviation, are there already, but contouring (interpolation), fft/dwt, filtering, etc... are missing.
• A generic plotting system, that doesn't depend on a specific widget library (yes, please, let's avoid holy wars there!). It could be done in a similar way as the optimizer architecture, with generic drawing functions, resolution independant (all coordinates double between 0 and 1 for example), and let the subclasses doing the actual rendering. This could at the same time offer an eps output seamlessly.
• More LAPACK wrappers.
• Use sparse, symmetric, diagonal and all the LAPACK storage types, probably by adding some code in translate_coord. Then possibly optimize the operators, like matrix multiplication on sparse matrices.
• Test and if necessary port it to other architectures than Linux on x368 & alpha processors, and IRIX64.
• If you feel that motivated, a m2cpp converter to translate m files.
• Anything else you'd like to see there!

Nicolas Brodu, 2000-06-17