ublas::bounded_vector>>正在调整大小？
现在，说真的……我不会在这里使用脏话，因为我们正在谈论 Boost 的同事。以这种方式看待事情一定是我的错误，但我不明白为什么，所以我会在这里问；也许有人可以在这件事上启发我。事情是这样的：
uBLAS 有一个名为 bounded_vector 的漂亮类模板，用于创建固定大小的向量（或者我是这么认为的）。
来自Effective uBLAS wiki (http://www.crystalclearsoftware.com/ cgi-bin/boost_wiki/wiki.pl?Effective_UBLAS):
默认的 uBLAS 向量和矩阵类型是可变大小的。许多线性代数问题涉及具有固定大小的向量。 2元和3元在几何中很常见！固定大小存储（类似于 C 数组）可以有效实现，因为它不涉及与动态存储相关的开销（堆管理）。 uBLAS 通过将向量/矩阵的底层存储从默认的“unbounded_array”更改为“bounded_array”来实现固定大小。
好吧，这个 bounded_vector<> 东西用于让您免于将向量的底层存储指定为指定大小的 bounded_array<>。这里我问你：这个有界向量的东西在你看来是不是有固定的大小？嗯，它没有。
起初我觉得维基背叛了我，但后来我重新考虑了“有界”的含义，我想我可以让它过去。但是，如果您像我一样（我仍然不确定），仍然想知道这是否有意义，我发现 bounded_vector<> 实际上可以调整大小，但可能只是不能大于模板参数指定的大小。
- 所以，首先，你认为他们有充分的理由不做一个真正的>>固定<<大小向量还是矩阵类型？
- 您认为可以将这个有界（而不是固定大小）矢量作为“固定大小”矢量“出售”给我的库的用户吗替换，甚至命名为“Vector3”或“Vector2”，就像Effective uBLAS wiki 所做的那样？
- 您认为我应该为此目的以某种方式实现一个具有固定大小的向量吗？如果是这样，怎么办？ （抱歉，但我对 uBLAS 还很陌生；今天刚刚尝试过）
- 我正在开发一款 3D 游戏。 uBLAS 是否应该用于涉及此的计算（“嘿，几何！”，根据 effective uBLAS wiki）？如果没有，您建议用什么替代品？
-- 编辑
以防万一，是的，我已经读过这个警告：
应该注意的是，这仅改变了 uBLAS 用于 vector3 的存储。 uBLAS 仍将使用相同的算法（假设大小可变）来操作向量3。实际上，这似乎对速度没有负面影响。上面的运行速度与不使用 uBLAS 的手工制作的 vector3 一样快。唯一的负面影响是向量 3 总是存储一个“大小”成员，在这种情况下是多余的[或者不是吗？我的意思是……]。
我看到它使用相同的算法，假设大小可变，但是如果一个操作实际上改变了它的大小，那么它不应该被停止（断言）吗？
ublas::bounded_vector<float,3> v3;
ublas::bounded_vector<float,2> v2;
v3 = v2;
std::cout << v3.size() << '\n'; // prints 2
哦，拜托，这不是纯粹的背叛吗？
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.
- So, first off, do you think they've had a good reason not to make a real >>fixed<< size vector or matrix type?
- 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?
- 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)
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ublas从来没有打算用于 3D 线性代数ublas。相反，我建议您使用cvalarray或 本征。两者都非常高效并且使用表达式模板。 Eigen2 甚至在某些情况下具有自动矢量化功能，提供求解器等...另请参阅 BoostLA，一个提交给 Boost 的新线性代数库。
ublaswas never meant to be used for 3D linear algebraublas. Instead, I suggest you usecvalarrayor 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.
游戏中的大多数内容通常都由 3D 引擎库支持。拥有大量有用的实用程序。例如，我使用过 Irrlicht（相对较小的引擎），但从未离开过它们整齐地集成的向量、矩阵和算法的世界。
对于 uBlas 来说仍然有效的一个论点是它是事物的增强解决方案。您可以将任何您想要的强大后端放在后面，并将其用于实际的繁重工作（搜索：boost numeric bindings for ublas）。然后，它充当其他库的抽象层，这对于模块化软件很有好处。因此，学习 uBlas 仍然是一个合理的练习，但是，就像大多数 boost 一样，它缺乏直观性，并且总是更喜欢通用性而不是可用性。 （我的忧郁又来了，对不起。）
简而言之：这是一项有价值的技能，但是您会从 3d 库提供的 linalg 或 eigen 中获得更多乐趣，后者有更好的文档记录并且围绕一个不错的库。
这也是让你感到恼火的轻微语无伦次的原因。
有界向量的接口应尽可能接近法线向量的接口。我同意你的例子中的效果看起来很邪恶。但是，如果您想与正常的 std::vector 行为方式保持兼容，则没有太多选择。
有界向量只是不做动态扩展的事情。
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.