ublas::bounded_vector<>正在调整大小？

Question

现在说真的..。我不想在这里说坏话，因为我们说的是助推的家伙。这样看一定是我的错，但我不明白为什么，所以我在这里问，也许有人能在这件事上启发我。下面是：

uBLAS有一个很好的类模板，名为bounded_vector<>，用于创建固定大小的向量(至少我这么认为)。

来自有效的uBLAS wiki (UBLAS)：

默认的uBLAS向量和矩阵类型是可变大小的。许多线性代数问题都涉及到具有固定大小的向量。2和3元素在几何学中很常见！固定大小的存储(类似于C数组)可以有效地实现，因为它不涉及与动态存储相关的开销(堆管理)。uBLAS通过将向量/矩阵的底层存储从默认的"bounded_array“更改为”bounded_array“来实现固定的大小。

好的，这个bounded_vector<>是用来将向量的底层存储指定为指定大小的bounded_array<>的。这里我问你:你不觉得这个有界向量的东西有固定的大小吗？嗯，它没有。

起初我觉得被维基背叛了，但后来我重新考虑了“有界”的含义，我想我可以让它过去。但是，如果您，像我一样(我仍然不确定)，仍然想知道这是否有意义，我发现bounded_vector<>实际上可以调整大小，它可能不会大于指定为模板参数的大小。

1. 那么，首先，您认为他们有充分的理由不做真正的>>固定的<<大小向量或矩阵类型吗？
2. 你认为向我的图书馆的用户“出售”这个有限的向量，而不是固定大小的向量，作为“固定大小的”向量替换，甚至命名为"Vector3“或"Vector2"，就像有效的uBLAS wiki那样，可以吗？
3. 你认为我应该在某种程度上实现一个固定大小的向量吗？如果是这样的话，是怎么做的？(对不起，我对uBLAS很陌生，今天刚试过)
4. 我正在开发一个3D游戏。是否应该使用uBLAS进行这方面的计算(“嘿，几何学！”，每个有效的uBLAS wiki)？如果没有，你会提出什么替代方案？

-编辑

以防万一，是的，我读过这样的警告：

应该注意的是，这只会改变uBLAS用于vector3的存储。uBLAS仍然将使用所有相同的算法(假设一个可变大小)来操作vector3。在实践中，这似乎对速度没有负面影响。上面的运行速度与手工构建的vector3一样快，它不使用uBLAS。唯一的负面影响是，vector3总是存储一个“大小”成员，在这种情况下，这个成员是多余的，不是吗？我是说..。

我看到它使用相同的算法，假设一个可变的大小，但是如果一个操作实际上要改变它的大小，它不应该停止(断言)吗？

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

噢，得了吧，这不是很明显的背叛吗？

Answer 1

1. ublas从来不适合用于三维线性代数。
2. 主观论证
3. 为了学习表达式模板，我在代码库中这样做，请参阅4。
4. 你正在开发一个3D游戏，然后忘记ublas。相反，我建议您使用cvalarray或本征。两者都非常高效，并且使用表达式模板。Eigen2在某些情况下甚至提供自动矢量化，提供求解器等。

也请参阅BoostLA，一个新的linera代数库提交给Boost。

Answer 2

游戏中的大多数东西通常都是由3D引擎库支持的。有很多有用的实用工具。例如，我使用了Irrlicht (相对较小的引擎)，但从未离开过它们完整集成的向量、矩阵和算法世界。

对于uBlas来说，一个仍然有效的论点是，它是事物的助推解决方案。您可以将任何您想要的强大后端放在后面，并将其用于实际的繁重工作(搜索:为ublas增加数值绑定)。然后，它作为其他库的抽象层，这对于模块化软件是很好的。因此，学习uBlas仍然是一个合理的练习，但是，就像很多boost一样，它缺乏直观性，而且总是喜欢泛泛性而不是可用性。(我的忧郁又开始了，斯里。)

简单地说，这是一项很有价值的技能，但是您可以更多地使用您的3d库提供的linalg，或者更好的文档化和一个很好的库周围的特征。

这也是让你感到不协调的原因。bounded_vector的接口应尽可能接近法向量的接口。我同意你的例子中的效果看起来是邪恶的。但是，如果您想要与普通的std::vector的行为保持兼容，那么您就没有太多的选择。

bounded_vector只是不做动态扩展的事情。