Eigen seems too strict enforcing its arguments-must-be-of-same-type policy in case of inner products, as demonstrated by the following example #include <Eigen/Core> namespace Eigen { namespace internal { template <> struct scalar_product_traits<float, double> { enum { Defined = 1 }; typedef double ReturnType; }; template <> struct scalar_product_traits<double, float> { enum { Defined = 1 }; typedef double ReturnType; }; } } int main(void) { Eigen::Matrix<double, 3, 1> dmat; Eigen::Matrix<float, 3, 1> fmat; // [ OK ] 3x1 * 1x3 = 3x3 dmat * fmat.transpose(); // [Fail] 1x3 * 3x1 = 1x1 dmat.transpose() * fmat.transpose(); return 0; } As far as I understand, the purpose of the scalar_product_traits template is to allow such mixed-type products via specializations and it indeed works as expected in the outer product case, but not for inner products. This seems to me like an oversight that can be easily fixed by removing the STATIC_ASSERTION in GeneralProduct.h in line 208. The GeneralProduct specialization for InnerProducts uses scalar_product_traits anyway, hence the validity of the expression is already ensured. (Btw. to counter any vectorization arguments against mixed-type arithmetic: Consider 'float' and 'double' in the above example as placeholders for more complex types (like boost::multiprecision or AutoDiffScalar) with appropriately overloaded operators for mixed type arithmetic)
I guess this was simply not backported to 3.2 -- your code works in the devel branch (if you remove the last .transpose(), which I guess was just a typo), and after this it should also work on 3.2: https://bitbucket.org/eigen/eigen/commits/72bc00590324 Thanks for the report!
You're absolutely right, the 2nd .transpose() was unintended. Thanks for the quick fix! Now for me to go upstream again, there just needs to be a way to use mixed types within .binaryExpr(...), but I guess I should open another bug report/feature request for that.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1176.