|
|
Ublas : |
Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-08-03 11:28:26
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?
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?
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.
3) But what if anyone wrote code that accessed the size_ member rather than
using the functions? Screw them... A good lesson in encapsulation.
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 but ran into at one
point.
5) Basically: If we want to rewrite c_vector because we don't like its
implementation, then just replace it.
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.
_Jesse