CI覆盖率

• 支持构建在: x86, x86_64, wasm32, armv7, aarch64, thumbv7neon
• 测试在: x86, x86_64, wasm32

如果你是CI专家，请提交一个PR，提供更多的CI覆盖率！

hektor

用于hekkin向量的库。

目标

• f32 维度为2、3和4的向量。
• f32 每列一个向量的矩阵（即“列主序”）。这对于通过GLSL着色器上传到OpenGL或Vulkan是最优的。
• f32 四元数。

状态：尚未准备好使用

代码组织细节

代码主要按每个模块一个类型进行组织。这些模块通过在lib.rs中对每个模块执行以下操作成为crate的一部分

mod foo;
pub use foo::*;

私有模块和对该模块内容的pub use的组合导致外部世界将foo模块的所有内容视为直接位于crate顶级模块中。这对最终用户来说更容易，而不必将整个crate放在一个文件中。

测试按每个操作组一个测试文件进行组织。在逐个添加操作并检查其是否针对每种适当类型实现时，这要容易得多。

内联策略

• 任何“访问器”和“视图”样式方法，以及new，都被标记为#[inline]。
• 大多数其他方法默认标记为#[inline]。
• 格式化方法甚至没有标记为内联。
• 如果可以证明不足的内联是导致性能下降的原因，那么我们可以将特定的方法升级为#[inline(always)]，但首先必须有一个基准测试来证明这个问题。

贡献

目前，我正在使用向库中添加新操作作为一种方式来重新验证我是否个人知道每个东西是如何工作的，因为自从我上次做这件事以来已经有一段时间了。因此，我不太感兴趣的是其他人添加大量功能。

话虽如此，有许多地方可以加快这个过程，供希望贡献的人帮忙。

• 并非所有操作都完美快速：基准测试库中任何潜在的慢操作，基准测试另一种计算相同方式的方法，如果你发现改进，请提交PR。
• 数学研究很难：查找操作的工作方式，并在问题跟踪器中的相应操作问题中发布适当的公式和源链接。这对于与四元数有关的内容尤为重要。
• 测试数据很无聊：根据操作公式，编写一些预期的测试用例，并在问题跟踪器中的相应问题中发布它们，这样我就可以提前知道目标是什么。如果已经有了测试用例，我更有可能首先尝试处理它，因为自己编写测试非常无聊。
• 创建新问题：如果有操作，尤其是nalgebra-glm处理的操作，不在问题跟踪器中，请将其添加到问题跟踪器中。
• 帮助我的依赖项：我正在尽可能长时间地保持no_std，这意味着我最终不得不依赖于libm crate，所以你总是可以在这里帮忙。
• 广泛执行：这是最困难的一个。对于Vec3/Vec4，我们希望尽可能利用单个组件作为“f32x4” SIMD通道的一部分。这意味着我们必须编写一些操作的自定义版本，特别是三角函数，因为正常的分支代码对我们帮助不大。例如，当在SIMD中有一个分支时，你必须执行两个分支，然后使用掩码将结果组合起来，所以提前退出函数的分支没有帮助。这通常意味着你必须重新思考如何处理事情。正确宽度的三角函数等是跨领域最终良好性能的关键。这不是一个硬性要求：如果没有宽版本，我就对每个组件单独调用必要的libm函数，但这大约需要执行4倍的时间。