Boost logo

Ublas :

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


Vardan Akopian wrote:

> On Fri, Jul 23, 2010 at 5:23 AM, Nasos Iliopoulos <nasos_i_at_[hidden]>
> wrote:
>>
>> If I remember well from my implelentation the major decision that has to
>> be made relates to the resize(..) member function. Since the fixed types
>> cannot resize it would seem obvious that those functions should not be
>> implemented at all, but I think uBlas is using it in some algorithms, so
>> either the algorithms need to be specialized, or the the fixed type
>> resize function needs to be implements as an empty function. I think the
>> first option is the best.
>>
>
> The idea of a fixed size vector has been discussed multiple times on
> this list over the years. Typically it has been rejected because the
> Vector Concept (as per
>
http://www.boost.org/doc/libs/1_43_0/libs/numeric/ublas/doc/container_concept.htm#vector
> ), defines the resize() method. Moreover it has a post condition
> v.size () == n. So not having an implementation would break the
> concept, having an empty implementation would break the concept's post
> condition. A third option is to throw an exception (saying that it
> cannot be resized). I'm not sure if throwing an exception technically
> breaks the concept. If it does not, then we're fine.
The bounded_array::resize method is defined as follows:

        void resize (size_type size) {
            BOOST_UBLAS_CHECK (size <= N, bad_size ());
            size_ = size;
        }

i.e., it throws an exception on an attempt to resize it above the upper
bound set at compile time. Since this code has been accepted in the boost
library, I think the following fixed_array::resize implementation should be
ok as well:

        void resize (size_type size) {
            BOOST_UBLAS_CHECK (size == N, bad_size ());
        }

> Otherwise, we should either consider changing the concept,
This is probably more work (although Nasos has an idea how to do this).

> or agree that
> fixed_vector does not implement the Vector concept (in which case
> naming it a "..._vector" is somewhat misleading).
This would be confusing since a fixed_vector should behave very much the
same as a bounded_vector and unbounded_vector with respect to its role in
vector and matrix expressions, only its resize() method behaves differently
(which is also the case for the bounded_vector vs. unbounded_vector).

        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