Boost logo

Ublas :

Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
From: Markus Grabner (grabner_at_[hidden])
Date: 2010-08-02 14:02:19


Nasos Iliopoulos wrote:

> Furthermore in order for this addition to be complete, fixed_vector and
> fixed_matrix classes should be implemented, that would be similar to
> bounded_vector and bounded_matrix (without the size member variables).
As I said in my previous message, fixed_vector was an easy exercise.
However, a fixed_matrix is much more complicated since ublas::matrix already
includes members "size1_" and "size2_" to define the matrix size. I don't
know of any method to "get rid of" these members in a derived class (such
that - again - a contiguous array of matrix coefficients can be cast to an
array of fixed_matrix). Instead I experimented with the following approach:

1.) rename ublas::matrix to ublas::matrix_base

2.) add an additional template parameter "S" to ublas::matrix_base which is
a class having methods "size1()" and "size2()" and from which
ublas::matrix_base is derived, i.e., the declaration looks like this:

    template<class T, class L, class A, class S >
    class matrix_base:
    public matrix_container<matrix_base<T, L, A, S> >, public S {
        ...

3.) create two classes "matrix_size_dynamic" and "matrix_size_static" which
can be used as template parameter "S" in ublas::matrix_base. The size*()
members of matrix_size_dynamic return the values of corresponding members
storing the current size of the matrix at runtime, the size*() members of
matrix_size_static return the fixed size of the matrix given as template
arguments at compile time.

4.) create a new ublas::matrix derived from ublas::matrix_base like this:

    template<class T, class L, class A>
    class matrix:
    public matrix_base<T, L, A, matrix_size_dynamic> {
        ...

While this worked well for some simple examples, I'm not sure whether it
would break existing code when expression templates are involved. Before I
dig deeper into this, I'd like to ask for comments about such an approach
(or if it can be done in a totally different way).

        Kind regards,
                Markus

-- 
Markus Grabner
Institute for Computer Graphics and Vision
Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria
WWW: http://www.icg.tugraz.at/Members/grabner