For the gemm/gemv templates customization, it looks like at that point, the data is already treated as arrays, so we don’t get to cast the entire matrix (once) at that point. I’m afraid of what it might mean. Would we end up with promotions done repeatedly?
So, I was looking for another way to accomplish the same thing. I noted in the matrix base implementations, a lot of the operators are member functions with one (non-implicit) argument. I thought perhaps it would be possible to define the binary version of the operators (like *) in the case where the complex type of one matrix and the scalar type of the other matrix are ummatched, and have it do the cast automatically. However, according to the CPP reference on operators and function overloading, I’m not sure how I could make a binary function a better fit for the same operator than the member function, because the binary function needs to sometimes promote either or both of the left and right operands. Since the member function has an exact match for its implicit this pointer, it seems like there’s no way to guarantee a shorter conversion sequence than the existing Eigen member functions.
Obviously, we could just tell people to use m1.lazyProduct(m2) or explicit casting as mentioned above from StackOverflow if they run into this error with dynamic sized matrices. (Fixed size doesn’t have the problem.) Also, in the same SO post, ggael said Eigen 3.4 was going to move to disable the advanced machinery we’re talking about here for custom types, though I’m on develop and it still happened to me, so it is possible that hasn’t landed yet… So, eventually, this last problem should just go away. I’ll comment on SO and point here in case ggael wants to add anything.