ublas::bounded_vector<> being resized?

Question

Now, seriously... I'll refrain from using bad words here because we're talking about the Boost fellows. It MUST be my mistake to see things this way, but I can't understand why, so I'll ask it here; maybe someone can enlighten me in this matter. Here it goes:

uBLAS has this nice class template called bounded_vector<> that's used to create fixed-size vectors (or so I thought).

From the Effective uBLAS wiki (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Effective_UBLAS):

The default uBLAS vector and matrix types are of variable size. Many linear algebra problems involve vectors with fixed size. 2 and 3 elements are common in geometry! Fixed size storage (akin to C arrays) can be implemented efficiently as it does not involve the overheads (heap management) associated with dynamic storage. uBLAS implements fixed sizes by changing the underling storage of a vector/matrix to a "bounded_array" from the default "unbounded_array".

Alright, this bounded_vector<> thing is used to free you from specifying the underlying storage of the vector to a bounded_array<> of the specified size. Here I ask you: doesn't it look like this bounded vector thing has fixed size to you? Well, it doesn't have.

At first I felt betrayed by the wiki, but then I reconsidered the meaning of "bounded" and I think I can let it pass. But in case you, like me (I'm still uncertain), is still wondering if this makes sense, what I found out is that the bounded_vector<> actually can be resized, it may only not be greater than the size specified as template parameter.

1. So, first off, do you think they've had a good reason not to make a real >>fixed<< size vector or matrix type?
2. Do you think it's okay to "sell" this bounded -- as opposed to fixed-size -- vector to the users of my library as a "fixed-size" vector replacement, even named "Vector3" or "Vector2", like the Effective uBLAS wiki did?
3. Do you think I should somehow implement a vector with fixed size for this purpose? If so, how? (Sorry, but I'm really new to uBLAS; just tried it today)
4. I am developing a 3D game. Should uBLAS be used for the calculations involved in this ("hey, geometry!", per Effective uBLAS wiki)? What replacement would you suggest, if not?

-- edit

And just in case, yes, I've read this warning:

It should be noted that this only changes the storage uBLAS uses for the vector3. uBLAS will still use all the same algorithm (which assume a variable size) to manipulate the vector3. In practice this seems to have no negative impact on speed. The above runs just as quickly as a hand crafted vector3 which does not use uBLAS. The only negative impact is that the vector3 always store a "size" member which in this case is redundant [or isn't it? I mean......].

I see it uses the same algorithm, assuming a variable size, but if an operation were to actually change its size, shouldn't it be stopped (assertion)?

ublas::bounded_vector<float,3> v3;
ublas::bounded_vector<float,2> v2;
v3 = v2;
std::cout << v3.size() << '\n'; // prints 2

Oh, come on, isn't this just plain betrayal?

Answer 1

1. ublas was never meant to be used for 3D linear algebra
2. subjective and argumentative
3. I did it in my code base for the sake of learning expression templates, see 4. for existing solutions
4. You're developing a 3D game, then forget about ublas. Instead, I suggest you use cvalarray or Eigen. Both are very efficient and use expression templates. Eigen2 even features auto vectorization in some situations, provides solvers, etc...

See also BoostLA, a new linera algebra library submitted to Boost.

Answer 2

Most things in games are usually supported by your 3D engine lib. With tons of useful utilities. e.g. I have used Irrlicht (relatively small engine) but never had to leave their neatly integrated world of vectors, matrices and algorithms.

The one argument that is still kind of valid for uBlas is that it is the boost solution of things. You can stick whatever powerful back end you want behind it and use that for the actual heavy lifting (search: boost numeric bindings for ublas). It then serves as an abstraction layer to other libraries which is good for modular software. Learning uBlas is therefore still a reasonable exercise, but, like much of boost, it lacks in intuitivity and always prefers generality over usability. (there goes my blues again, sry.)

In a nutshell: It is a valuable skill, but you will have more fun with the linalg that your 3d lib provides or eigen which is better documented and all around a nice library.

That is also the reason for the slight incoherence that irked you. The interface of bounded_vector should stay as close as possible to the interface of a normal vector. I agree that the effect in your example looks evil. But if you want to stay compatible to how the normal std::vector behaves, you have not much choice.

bounded_vector just doesn't do the dynamic expansion stuff.