Yup. That part is perfectly clear.
The part that isn’t clear at all is what’s the gain? (I really don’t know what we gain from this. Not saying that there aren’t any; I just don’t know what they are.)
To summarize the potential problems:
- maintenance: shifting API means that single use of
Eigen::Tensormay not be compatible across different Eigen versions, so the math version would then have to be linked to an Eigen version. (Right now, we don’t have that sort of requirement, but maybe we should?)
- RStan installation: not sure if RcppEigen already ships
Eigen::Tesnor. If it’s an incompatible version with Stan Math, then the installation process for RStan becomes much more complicated.
- dependency management: we’re now in a wag the dog situation where the Stan Math library wouldn’t be able to shift off of Eigen versions because of RStan’s dependency on RcppEigen’s version.
- compiler issues: given how much effort we put in to work around multiple versions of Eigen and different OSes and compilers, I’m going to assume getting
Eigen::Tensorto work is going to be difficult. I’m guessing we haven’t figured out how to compile against g++7 yet? Given how much trouble PyStan already has compiling models with Eigen, I’m going to guess this is going to make it worse.
Anyway, I’m not trying to disparage. I just want to know that the pros (or even the potential pros) outweigh the list of things I know we’re going to face.