A seemingly trivial change to a published example breaks algebra_solver (?)

Algorithms
1

I’m trying to do exactly what @betanalpha described in his case study on Gaussian processes, namely add an informative prior for the length scale parameter rho in cov_exp_quad as described in section 4 of part 3 of his case study. To get started I just copied and pasted his code for using the new algebra_solver and got the following:

> fit <- stan(file="gp_prior_rho.stan",iter=1,warmup=0,chains=1,seed=5838298,algorithm="Fixed_param")
hash mismatch so recompiling; make sure Stan code ends with a blank line

...

a = 8.91924
b = 34.5805

SAMPLING FOR MODEL 'gp_prior_rho' NOW (CHAIN 1).
Iteration: 1 / 1 [100%]  (Sampling)

 Elapsed Time: 0 seconds (Warm-up)
               1.1e-05 seconds (Sampling)
               1.1e-05 seconds (Total)

Next I changed one line of code to values appropriate for my models:

  vector[2] theta = [0.125, 1.0]';

and got:

trying deprecated constructor; please alert package maintainer
Error in new_CppObject_xp(fields$.module, fields$.pointer, ...) : 
  no valid constructor available for the argument list
failed to create the sampler; sampling not done

sessionInfo, etc.

> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Fedora 27 (Workstation Edition)

Matrix products: default
BLAS: /usr/local/lib64/R/lib/libRblas.so
LAPACK: /usr/local/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] akima_0.6-2        rstan_2.17.2       StanHeaders_2.17.1 ggplot2_2.2.1     
[5] tibble_1.3.4       readr_1.1.1        zernike_3.4.0     

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.12      hms_0.3           munsell_0.4.3     viridisLite_0.2.0
 [5] colorspace_1.3-2  lattice_0.20-35   R6_2.2.2          rlang_0.1.2      
 [9] plyr_1.8.4        tools_3.4.1       parallel_3.4.1    grid_3.4.1       
[13] gtable_0.2.0      cosmo_0.1.1       lazyeval_0.2.0    digest_0.6.12    
[17] gridExtra_2.3     viridis_0.4.0     codetools_0.2-15  inline_0.3.14    
[21] labeling_0.3      sp_1.2-5          compiler_3.4.1    scales_0.5.0     
[25] stats4_3.4.1     
> system("cpp --version")
cpp (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I get the same error on a fresh Windows installation.

2

Try installing rstan from GitHub via

devtools::install_github("stan-dev/rstan", branch = "develop", 
                         subdir = "rstan/rstan")

but it is telling you that you passed the data wrong somehow.

3

I got a fatal error when I tried to compile rstan from the develop branch, but never mind. The main problem was that I didn’t spend much - actually any - time thinking about reasonable scale/shape values for the range of lengths I’m looking at, and the ones in the code snippet aren’t close.

After exposing the stan function and playing around a bit values of (a, b) around (8, 2) looked pretty close, so I changed lines 11-12 of @betanalpha’s code to

  vector[2] y_guess = [log(8), log(2)]';
  vector[2] theta = [0.125, 1.]';

and stan returned

 a = 5.558
b = 1.5562

SAMPLING FOR MODEL 'gp_prior_rho' NOW (CHAIN 1).
Iteration: 1 / 1 [100%]  (Sampling)

 Elapsed Time: 0 seconds (Warm-up)
               1.1e-05 seconds (Sampling)
               1.1e-05 seconds (Total)

As a check:

> tail_delta(c(log(5.558),log(1.5562)),c(.125,1.),c(1.),c(1))
[1] -1.794685e-08 -1.295277e-08

The error message didn’t exactly put me on the right track, but it seems the starting guess must be within shouting distance of correct for algebra_solver to work. Shouldn’t be a surprise.