# Refactoring math with more general signatures
**URL:** https://discourse.mc-stan.org/t/refactoring-math-with-more-general-signatures/10157
**Category:** Developers
**Tags:** math
**Created:** [August 13, 2019, 1:17pm UTC](https://discourse.mc-stan.org/t/refactoring-math-with-more-general-signatures/10157 "2019-08-13T13:17:23Z")
**Posts on this page:** 1
**Showing post:** 6
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [August 20, 2019, 8:48pm UTC](https://discourse.mc-stan.org/t/refactoring-math-with-more-general-signatures/10157/6 "2019-08-20T20:48:38Z")
> [@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\
`add` can be a bit more general in that `T1` or `T2` can be scalars.
---
_[View the full topic](https://discourse.mc-stan.org/t/refactoring-math-with-more-general-signatures/10157)._