|
|
Ublas : |
Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
From: Markus Grabner (grabner_at_[hidden])
Date: 2010-08-03 18:39:25
Jesse Perla wrote:
> Nasos Iliopoulos <nasos_i <at> hotmail.com> writes:
>>
>>
>> All,The fixed array is a good idea and I think this should be considered
>> to be
> included in ublas. This would allow for small size vectors and matrices to
> work in near optimal state (i.e. something like defining a struct vec3d
> {double
>
> Hi guys,
> I am a big user of fixed sized vectors all over the place and would love
> to have a near optimal version (would be great to be able to complete with
> Eigen on performance using whatever vectorization we need at some point in
> the future).
>
> But even after reading this thread, I am still incredibly confused as to
> why
> c_vector shouldn't just be fixed rather than adding a new one. What is
> the fundamental problem and what benefit do the 2 implementations give us?
There is already some redundancy in the code (e.g., bounded_vector and
c_vector both have a dynamic size with an upper limit), introducing the
fixed vector/matrix classes neither causes nor solves this problem. Changing
the behaviour of a class (e.g., by modifying c_vector to be of fixed size)
will likely break existing code. I am not familiar with boost's policy of
deprecating/removing features and breaking backwards compatibility. Maybe
somebody with more insight into this can comment?
> 1) the size_ member variable? Can't we just get rid of it in the
> implementation and use the static size as the implementation for all
> vectors?
Do you also mean ublas::vector and ublas::bouded_vector by "all vectors"? I
think there are enough use cases to justify those having a dynamic size (and
hence the size_ member variable).
> 2) the 'resize()' function? Just empty function as discussed in this
> thread,
> along with a static assertion. I ran into the 'resize' interface on
> constant size vectors all the time when writing generic code, and the
> alternative metaprogramming to conditionally call resize() would have been
> ugly as sin. Not to mention the features needed in the numeric traits to
> detect resizable, etc. Keeping around resize() is a least bad solution.
I agree with this.
> 3) But what if anyone wrote code that accessed the size_ member rather
> than
> using the functions? Screw them... A good lesson in encapsulation.
Aren't all the size_ etc. private? It shouldn't be possible to use them at
all outside of the class definition.
> 4) Are there problems with the current c_vector not fulfilling the
> requirements
> of POD? This is something that I don't know much about
Me neither...
> 5) Basically: If we want to rewrite c_vector because we don't like its
> implementation, then just replace it.
Modifying the behaviour of c_vector might result in existing code showing
differnt runtime behaviour, which is very bad. Just removing the class will
at least make sure that existing code can no longer be compiled (and
silently misbehave), such that the developer is forced to consider
alternatives, which is less bad IMO.
> I am sure I have repeated thoughts in this thread, but just wanted to put
> in my vote for keeping the number of interfaces/vector types to a minimum.
>
> It is going to be incredibly confusing and add a huge number of test cases
> to
> have 2 almost identical vector types. And I am terrified that features
> will be added to 1 and not the other.
Indeed this should be cleaned up, but it's more a question of bounded_vector
vs. c_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