Autogenerate code for stan models on installation

[andrjohns]

Once StanHeaders 2.31 (eventually) is distributed, the model.hpp file in your package will fail to compile. This PR updates your package to use the autogen.R script to generate and appropriately modify the .hpp for each upcoming combination of rstan and StanHeaders.

Let me know if you have any questions/concerns. Thanks!

[kaskr]

@andrjohns This is really great - thanks!

I'm having some trouble getting it to work though. I'm currently using:
[1] rstan_2.21.3 StanHeaders_2.21.0-7
and get this error during install from the new fancy bounds function:

TRANSLATING MODEL 'tmb' FROM Stan CODE TO C++ CODE NOW.
SYNTAX ERROR, MESSAGE(S) FROM PARSER:
Expression denoting real required; found type=vector.
 error in 'model_tmb' at line 18, column 15
  -------------------------------------------------
    16: }
    17: parameters {
    18:   vector<lower=make_bounds(lower_bound, N, 0),
                      ^
    19:           upper=make_bounds(upper_bound, N, 1)>[N] y;
  -------------------------------------------------

PARSER EXPECTED: <expression>
Error in rstan::stanc(stan_file, model_name = "tmb", verbose = TRUE, obfuscate_model_name = FALSE) : 
  failed to parse Stan model 'tmb' due to the above error.

FWIW, the configure script chooses your new stan script here

if (utils::packageVersion("rstan") <= 2.21) {
  stan_file <- "inst/model.stan"
} else {
  stan_file <- "inst/model226.stan"
}

I wonder if 2.21 really is right? When I force it to use the old model it works...

[andrjohns]

Ah I see my mistake in the conditional, I'll push the fix now

[kaskr]

OK thanks, that fixes the build problem for current CRAN versions of rstan and StanHeaders.
I compiled tmbstan and ran the test script from the main folder:
https://github.com/kaskr/tmbstan/blob/master/test.R
All tests are passing to machine tolerance.

I could also update to rstan_2.26.18 StanHeaders_2.26.18 and rebuild tmbstan without problems.
However, the tests are now all failing. For instance, comparing the 1st iteration of two fits that are supposed to be identical, I get:

> round(as.array(fit1)[1,,] - as.array(fit1.)[1,,],6)
         parameters
chains         y[1]      y[2]      y[3]      y[4]      y[5]      lp__
  chain:1  0.000000  0.000000  0.000000  0.000000  0.000000  0.000000
  chain:2  0.005968 -0.000330 -0.008760 -0.005539  0.010565 -0.000157
  chain:3 -0.000017 -0.000189  0.000052 -0.000031 -0.000212  0.000158
  chain:4 -3.537499  1.365013  2.025452  1.974103  0.140895  0.902766

So far I have no clue what could cause this.

[andrjohns]

Can you try the tests with the 2.26 versions and just the CRAN tmbstan? So I can rule out whether it's these modifications or changes to the Stan source that are the culprit

[kaskr]

With tmbstan_1.0.4 rstan_2.26.18 StanHeaders_2.26.18 the tests are failing in the exact same way.

[andrjohns]

It looks like this might partly be due to changes in how the chain values are extracted, if I change the test to using chains=1, then the difference drops:

> compare(fit1, fit1.)
MAX(ABS(DIFFERENCE)))
[1] 8.478106e-07

[andrjohns]

Looks like that's a red herring unfortunately, changing the seed shows the mismatch still

[andrjohns]

Got it! It's something to do with the normal(0,1), if I change those in the test to std_normal(), all passes. This is a Math library issue which I'll feed upstream, nothing for your package

Note that the tests fail with the CRAN tmbstan and rstan 2.26.x for any of the models with bounds, but pass with this version (differences in how adjustments are applied, I would guess)

[kaskr]

Wow, thanks for spotting this - I would never have guessed to try std_normal !

Note that the tests fail with the CRAN tmbstan and rstan 2.26.x for any of the models with bounds

Weird, I actually find the opposite: After using std_normal all tests (including those with bounds) pass with CRAN tmbstan and rstan 2.26.x.

[andrjohns]

Weird, I actually find the opposite: After using std_normal all tests (including those with bounds) pass with CRAN tmbstan and rstan 2.26.x.

Well no complaints from me for on a passing test! Let me know if you run into any other issues with this PR, it would be great to get it on CRAN soon to minimise the transition from 2.26 -> 2.31