Re: [boost] 2D Matrix

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 (http://tinyurl.com/ymjsoz),
along with two other submissions.  (Mine is geometryJH_01.zip).

-Jason

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: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>