Eigen矩阵标量运算API设计疑问：加与除为何处理不同？

问题示例代码 #

#include <Eigen/Core>

using Matrix = Eigen::Matrix<float, 2, 2>;

Matrix func1(const Matrix& mat) { return mat + 0.5; } // 无法编译
Matrix func2(const Matrix& mat) { return mat / 0.5; } // 可正常编译运行

func1无法编译，必须将mat替换为mat.array()才能实现逐元素加标量的操作；而func2无需转换即可直接完成逐元素除以标量的操作。

设计原因分析 #

Eigen的核心设计理念是明确区分矩阵代数操作和逐元素操作：

• 矩阵代数操作严格遵循线性代数规则，比如矩阵相加要求维度匹配、矩阵乘法遵循行列对应规则等。而「矩阵加标量」并不是标准的线性代数运算（线性代数中只有标量乘矩阵，或者标量乘单位矩阵再加矩阵这类合法操作），所以Eigen默认不提供该运算符，强制开发者通过array()显式切换到逐元素操作模式，避免误将非标准操作当成合法的矩阵代数操作。
• 「矩阵除以标量」等价于「矩阵乘以该标量的倒数」，这是标准的线性代数缩放操作，同时也和逐元素除法的结果一致。因此Eigen直接支持Matrix类的标量除法运算符，既符合线性代数语义，也满足逐元素操作的需求，不存在歧义。

自定义operator+的问题及原因 #

若为Matrix类添加如下方法：

auto operator+(Scalar s) const { return this->array() + s; }

会引发以下问题：

1. 语义歧义：该方法会将「矩阵加标量」默认解析为逐元素操作，但部分开发者可能期望的是「标量乘单位矩阵后加矩阵」（这是线性代数中唯一合法的类似操作）。这种歧义会导致代码行为不符合预期，且降低可读性——其他开发者无法仅凭运算符判断是逐元素操作还是矩阵代数操作。
2. 破坏API一致性：Eigen通过matrix()和array()明确划分两种操作模式的设计被打破，原本需要显式声明的逐元素操作变得隐式，违背了Eigen的设计初衷，增加了代码维护成本。
3. 重载冲突风险：Eigen内部大量使用模板和表达式模板优化，自定义的operator+可能与现有重载（比如矩阵间加法、矩阵与其他Eigen类型的加法）产生重载解析冲突，导致编译错误或意外的行为。

而operator/不存在这些问题的原因是：矩阵除以标量的操作在线性代数语义和逐元素语义下结果完全一致，Eigen内置的operator/已经实现了逐元素除法，同时符合线性代数的缩放规则，不存在歧义或冲突的可能。

内容的提问来源于stack exchange，提问作者dshin