Refactoring math with more general signatures

[Bob_Carpenter]

@stevebronder

Dan points out that Eigen coefficient access doesn’t work well with MatrixBase . Though Ben points out that A.coeff() for access instead of operator() would be sufficient to handle the coefficient access error Dan saw.

We should be moving from operator() and operator[] (just vectors) to .coeff. It doesn’t check ranges, but we do that everywhere ourselves, so the checks are (largely? totally?)

@stevebronder

Using Matrix, MatrixBase, EigenBase, or auto almost always gives the same assembly output.

Cool! Presumably it’s not the same code with Matrix and MatrixBase if you pass it an expression template; I’d have thought Matrix would .eval() and the base not.

@stevebronder

All the asm is the same except for auto which is actually inlined and a bit more optmized

@stevebronder

If we are careful with auto we can and should use it for function signatures because it performs better on clang 6.

It can be problematic as they note in the Eigen doc if you wind up saving something unevaluated rather than copied as it can imply a lot more eval downstream.

@stevebronder

enable_if_all_eigen<T1, T2>

add can be a bit more general in that T1 or T2 can be scalars.