|
|
Ublas : |
Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
From: Markus Grabner (grabner_at_[hidden])
Date: 2010-08-02 14:03:58
Karl Meerbergen wrote:
> Jesse Perla wrote:
>> Vardan Akopian <vakopian <at> gmail.com> writes:
>>
>>> ), 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. Otherwise, we
>>> should either consider changing the concept, or agree that
>>> fixed_vector does not implement the Vector concept (in which case
>>> naming it a "..._vector" is somewhat misleading).
>>>
>>
>> I strongly prefer having the .resize() function on any constant sized
>> vector to aid in generic programming (exactly for this reason).
>>
>> The solution to me seems that .resize() should exist, but it should
>> assert that you are trying to resize it to the exact same size as the
>> fixed size (at which point it becomes a null operation), or else it
>> throws an exception. This has come up in my code more than once.
>>
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: karl.meerbergen_at_[hidden]
>>
>
>
> I am really surprised to see that resize() should be a member function
> of a vector. Usually, in numerical codes you avoid to do resizes and
> many numerical algorithms do not require resizes at all (fortunately). I
> would make an additional concept for a ResizableVector.
I think a resize() is at least convenient if the vector size is not known at
compile time, e.g., if the vector is read from a file. Being able to mix
unbounded/bounded/fixed vectors in the same expression is a nice thing to
have, I'm not sure whether this is possible when vectors implementing
different concepts appear in the same expression.
Nevertheless, I propose to add a fixed_vector which fits into the existing
implementation as closely as possible since this would be a very easy
extension. More sophisticated approaches can then be discussed as needed
based on a working solution.
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