The Matrix Template Library
Generic Components for High Performance Scientific Computing
  Search | Support |  Download 
 The MTL FAQ
 Introduction and General Information

What is MTL?

The Matrix Template Library (MTL) is a collection of generic components for high performance scientific computing.

MTL is not a "class library." The fundamental paradigm behind a class library is object-orientation. The fundamental paradigm behind MTL is genericity. (Just because MTL is written in C++ does not make it object-oriented -- generic programming is an independent paradigm from object-oriented programming.)

How do I install MTL?

See the INSTALL file in the MTL distribution for complete instructions. The basic steps are to invoke configure with appropriate options and then to make install. Since MTL is a collection of components consisting entirely of header files, there are no executables or libraries to be compiled as part of the installation process. Invoking make install simply copies the header files to the directory specified when you invoke configure (the default is /usr/local/include).

Where is the documentation?

The latest version of the MTL documentation can always be found on line at this site. In addition, the programmer's guide, in HTML format, is bundled in the MTL distribution. Finally, if you must have hardcopy, Jeremy's thesis contains a printable version of the documentation, although it is a snapshot in time of Spring 1999. At some point we will fix perceps to reliably spew both html and latex at which point up-to-date hardcopy should be available consistently on this site.

What happened to Version 1?

"Be prepared to throw one version away, because you will anyway." -- F. Brooks, The Mythical Man Month.

 How To

How can I use MTL in conjunction with Blitz?

The easiest way (currently) to use MTL with Blitz arrays is to get a pointer to the data from the Blitz array (and also the stride information, also know as leading dimension) and construct an MTL matrix out of it (I call these matrices with "external" storage, and the constructors are documented as the "external data constructors"). You will want to look at matrices of type:
matrix < T, rectangle<>, dense < external > , row_major >::type
or
matrix < T, rectangle<>, dense < external >, column_major >::type

How do I use MTL with LAPACK?

See the lapack examples.

How do I read in matrix or vector data files?

See the examples.

How do I invert a matrix?

The first question you should ask yourself is whether you want to really compute the inverse of a matrix or if you really want to solve a linear system. For solving a linear system of equations, it is not necessary to explicitly compute the matrix inverse. Rather, it is more efficient to compute triangular factors of the matrix and then perform forward and backward triangular solves with the factors. More about solving linear systems is given below. If you really want to invert a matrix, there is a function lu_inverse() in mtl/lu.h.

How do I solve a linear system?

The core MTL functionality does not address the solution of linear systems. MTL algorithms supply basic linear algebra functionaliy from which solvers can be built. We have built a library of iterative methods, named the Iterative Template Library. We have also constructed an LU factorization algorithm (in mtl/lu.h), which is the beginning of a library of generic algorithms for the direct solution of dense linear systems.
 Problems

How do I configure MTL to use KCC?

The MTL distribution uses configure to set up all of the Makefiles in the distribution tree. One of the things that gets set up when configure is run is the C++ compiler. To get configure to set you up with a particular compiler (in this example, KCC), issue the following commands (assuming csh) prior to running configure (with whatever other options you may be using):
unix% setenv CXX KCC
unix% setenv CCC KCC
unix% /bin/rm config.cache

What does this error message mean?

Coming soon - an annotated list of common error messages.

These error messages are impossible to understand?

Coming soon - an annotated list of common error messages.
 About MTL

What platforms are supported?

Presently, we have tested MTL on the following platforms:

  • IRIX64 6.4
  • SunOS 5.6
  • Linux 2.0.35
  • Windows NT
Since the compiler is the most important issue (see below), we expect that MTL will also work on closely similar platforms (e.g., SunOS 5.5).

What compilers are supported?

MTL should work with any compiler that completely supports the ANSI C++ standard. The following compilers have been tested and are known to work:
  • SGI
    • MIPSpro Compilers: Version 7.3
    • KAI C++ 3.3f
  • Solaris
    • KAI C++ 3.3e
    • egcs-2.91.60 (which is called version 1.1.1)
  • Linux
    • KAI C++ 3.3g
    • egcs-2.91.60
  • Windows NT
    • g++-2.95 (using cygwin)
    • Visual C++ 6.0
    • Metrowerks CodeWarrior Pro 5
MTL is know NOT to compile with the Sun CC version 5.0 compiler (it does not support member templates!). For commercial compilers, it seems that compilers based on the Edison Design Group front end are able to compile MTL.

We have not yet checked the Intel C++ compiler, but the port should be easy. Nothing is known about other Windows compilers (e.g., Borland) at the present time.

Why is MTL written in C++ and not Fortran?

MTL has two particular strengths: genericity and high performance. To implement MTL, a language must support genericity and it must offer high performance. Presently, there are various languages that offer one or the other of these, but only C++ offers both. Fortran, for instance, has the reputation of offering high performance. However, it does not support generic programming. As our performance results clearly show, C++ can provide performance on par with Fortran.

There are even some applications where the presence of higher-level abstractions can allow significantly higher performance than Fortran.

Why is MTL written in C++ and not Java?

The Java language was developed for certain particular purposes. Scientific computing was not one of those purposes. Generic programming was not one of those purposes.

To offer sufficient performance for scientific computing, Java must be compiled to native object code, not byte code. To provide genericity, the Java language would have to be changed to include operator overloading and templates. Hmm. Templates, overloading, compilation to native object code.

On top of all that, Java has some problems with its floating point model.

I don't like the syntax of MTL algorithms. Why don't you use operator overloading?

Implementing operator overloading for a linear algebra is a non-trivial task. To get high performance one must use the expression template (ET) technique, and applying ET to linear algebra operations is more complicated than applying it to array (element-wise) operations. In addition, most current ET frameworks use advanced C++ language features such as partial specialization which prevents portability to bad C++ compilers. We are currently working on ET for MTL, and even hope to make it portable, but it will take some time.
 Miscellaneous

Can I use MTL on commercial projects?

Yes, the MTL is free for commercial use.

 About This Site

How did you create this site?

We tried to automate the process of site creation and maintenance to the largest degree possible. The MTL component documentation was extracted from source code using a perl-based tool called perceps (somewhat hacked for our own purposes). The other pages were constructed based on on hand-edited php3 templates (using emacs). Finally, some stylistic elements are controlled with a cascading style sheet.

Images, shadows, stylized text were created using the Gimp.

Being somewhat artistically impaired, we found creating the site look and feel to be one of the hardest parts of this entire effort. Drawing and placing the little 5 pixel by 5 pixel shadows to get the corner shadows was the least fun (and they still don't look all that great).

No WYSIWYG or GUI web site tools were used in the creation of this site.

If you have comments or suggestions, email mtl-devel@osl.iu.edu
Author: Andrew Lumsdaine, Jeremy Siek Lie-Quan Lee
E-Mail: lums@osl.iu.edu, jsiek@osl.iu.edu, llee@osl.iu.edu
Created: July 27, 1998
Modified: Thu 24-Aug-2006 EST
Copyright ©1997-2008