Boost logo

Boost :

From: Jason Hise (0xchaos_at_[hidden])
Date: 2006-11-08 00:57:08

I did something very much like this a while back, which was submitted
as a potential jumping off point for a boost geometry library. It is
in the boost vault under Math - Geometry (,
along with two other submissions. (Mine is


On 11/7/06, Jason Kraftcheck <kraftche_at_[hidden]> wrote:
> Hi,
> I have written a simple 2D matrix template where the extents of the matrix are
> template parameters. The multi_array container and the uBLAS matrix class both
> provide matrices of fixed dimension (template parameter for multi_array and 2
> for uBLAS) but variable extents. I think my matrix definition is complementary
> to these. There are several advantages to having an array of fixed extents; but
> the implementation is, of course, unusable when the extents are not known at
> compile-time.
> If the extents of the matrix are part of the type, the compiler can enforce
> correct matrix extents for operations, avoiding the cost of runtime checks. For
> example:
> double b[3][2] = { ... };
> matrix<3,3> A(2.0); // 2 * identity
> matrix<3,2> B(b);
> matrix<2,3> C;
> matrix<3,2> D;
> D = A * B; // OK
> C = A * B; // compile error - mismatched types
> C = transpose(B) * A; // OK
> Optimizing compilers can trivially unroll the loops used to define the
> operations. Use of this class does not require heap allocation. The storage
> required for the matrix is the minimal possible (assuming no assumptions about
> the values of the elements.) An array of matrices can be "serialized" to an
> array of doubles with a single reinterpret_cast.
> The proposed implementation is unsuitable for very large matrices: defining the
> element storage as a contiguous array may be problematic, most of the
> performance gains become insignificant, and the implicit copying will become
> significant.
> I've attached my current implementation. In it's current form, it is unsuitable
> for inclusion in Boost. I will fix any required issues if there is any interest
> in including it in Boost. The things that need to be changed (that I'm aware
> of) are:
> o license - GPL is not acceptable for Boost
> o naming (namespace and class name)
> o change explict 'double' for element type to a template parameter
> Some other changes that should probably be done before inclusion:
> o implement inverse for other than 2x2 and 3x3 matrices
> o more efficient determinant implementation for larger matrices
> o LU factorization
> o QR factorization
> In timing tests using G++ 4.1 on a Linux/Pentium4 platform, the performance of
> the arithmetic operations was equivalent to those of a special 3x3 matrix
> implementation with all operations explicitly unrolled (the 'old' implementation
> this one was to replace.)
> Is there any interest in including such a matrix definition in Boost?
> Is there already an effort to include something equivalent? I searched back a
> few years in the mailing list archive and didn't notice anything.
> Any suggested changes (other than those I listed above) for the attached
> implementation?
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at