Main Page | Modules | Namespace List | Class Hierarchy | Alphabetical List | Class List | Directories | File List | Namespace Members | Class Members | File Members

Non-member C-style functions
[Linear Algebra library]

Collaboration diagram for Non-member C-style functions:

A vast array of non-object-oriented functions, these methods calculate things and interface between C++ and BLAS. More...


Modules

 Testing Compatibility
 Methods that test whether a pair or triple of linear algebraic objects can be combined mathematically.
 Copying and assignment
 Non-member methods that copy one object into another.
 Unary operations
 Methods that act on a single object.
 Addition and subtraction
 Non-member methods that add or subtract one object from another.
 Scalar multiplication
 Non-member methods that multiply a matrix or vector by a scalar.
 Multiplication
 Non-member methods that multiply one object by another.
 Dot products
 External methods that compute the dot product between two objects.
 LAPACK routines
 Interfaces to sophisticated linear algebraic algorithms from LAPACK.

Detailed Description

A vast array of non-object-oriented functions, these methods calculate things and interface between C++ and BLAS.

Almost all of the pleasantly object-oriented methods for doing things to linear algebraic objects (primarily operators, either members of classes or global binary operators) call these C-style functions to their dirty work. "C-style" indicates not that they are written in ANSI C (their arguments are templated parameters, and use other C++ functionality, especially pass-by-reference), but that they are fundamentally non-object oriented in design.

Their design is optimized for efficiency rather than for "math-like syntax"; for instance, they return complex structures by computing them directly into a "result" parameter that must be provided, rather than by pushing them onto the stack.

When possible, these routines interface with BLAS (routines that will try to use BLAS are noted in the documentation. However, they provide all the basic linear algebra functionality, such as vector addition or matrix multiplication, independently of BLAS. Each function is overloaded to operate both on abstract types (e.g., Vector<T>, Matrix<T>) and on specific common variants (DenseVector<T>, DenseMatrix<T>). The "result" parameter, however, must always be a Dense object -- abstract types cannot be constructed and cannot necessarily be written to.

The Dense variants will try to use BLAS, but may be unable to do so. Dense objects can be "sliced", i.e. stored in noncontiguous blocks of memory. For example, consider the extraction of a RowVector and a ColumnVector from an $ N\times N$ DenseMatrix. It is not possible for both to have their elements stored in consecutive memory locations. Since the LinAlg library respects the FORTRAN convention of storing matrices in column-major order, the ColumnVector will be stored in a contiguous block of $ N $ memory locations, while the RowVector will occupy $ N $ locations spaced at intervals of $ N $ apart. This sort of disjointedness can be handled by the BLAS library; it is known as the "stride" of the object. However, BLAS cannot handle:


Generated on Wed Jun 14 22:25:31 2006 for linalg by  doxygen 1.4.4