(R)Stan 1.3.0 released

[Bob Carpenter]

Stan 1.3.0 and RStan 1.3.0 are available for download.
Follow the links on:

Stan home page: http://mc-stan.org/

Please let us know if you have problems updating.

- Stan Development Team


v1.3.0 (12 April 2013)
======================================================================

Enhancements
----------------------------------
Modeling Language
* forward sampling (random draws from distributions)
in generated quantities
* better error messages in parser
* additional distributions:
+ exp_mod_normal
+ gumbel
+ skew_normal
* additional functions:
+ owenst
* broadcast (repetition) functions for vectors, arrays, matrices
+ rep_arrray
+ rep_matrix
+ rep_row_vector
+ rep_vector

Command-Line
* added option to display autocorrelations in the command-line program
to print output
* changed default point estimation routine from the command line to
use Nesterov's accelerated gradient method, added option for point
estimation with Newton's method

RStan
* added method as.mcmc.list()
* compatibility with R 3.0.0

C++/Internal
* refactored math/agrad libs in C++ to separate files/includes,
remove redundant code, more unit tests for existing code
* added chainable_alloc class for caching solver results
* generalized VectorView with seq_view
* templated out generated code for efficient double-only operation
on model log probs w/o gradients

Doc
* additions to user's guide w. sample models
+ stochastic volatility example with source, optimized source,
simulation
+ time series, moving average, standardization for linear
regression, hidden Markov models, with examples
* manual's index is now hyperlinked
* added additional acknowledgements to manual
* added full description of differences between sampling
statement and lp__
* fixed general normal mixture model example

Testing
* split unit tests from distribution tests

Bug Fixes
----------------------------------
* fixed derivative in multi_normal_prec distribution function
* double-based log_prob functions return the same value as var-based
log_prob_grad functions
* calls to lgamma are now using boost's lgamma function
* patched transform to work with Eigen 3.2 beta
* all probability distribution functions and cumulative distribution
functions behave properly with 0 length vector arguments
* fixed error in definition of hypergeometric pmf
* fixed arguments to nesterov optimization ctor in command
* fixed issue with initialization matrices being read improperly
* Use fabs() instead of abs() in unit_vector_constrain.
* typos in the manual
* rstan:
+ fixed crash in R when index is out of bounds using set_cppo("fast")
+ io_context fix skipping len=0
+ fix the typo in manual (dims -> dim)
+ add require(inline) to fix the problem with loading sysdata.rda

[Steve]

Great work - downloaded Rstan and running without a problem. 

One question: The following fix is listed in documentation: * fixed general normal mixture model example

I compared stan-reference-1.3.0.pdf chapter 10 with stan-reference-1.2.0.pdf chapter 10, and could not find a difference with the stan code for normal mixture models. Where is this fix to which you refer? 

Thanks.

[Bob Carpenter]

I added a test model and some code in R to test
that it got the right results. Probably shoudln't
even have put that in the release notes -- sorry
for the confusion.

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Steve]

It's very helpful to have the examples in .stan and .R files. Thanks!

I found them on github:

.stan        https://github.com/stan-dev/stan/blob/master/src/models/basic_estimators/normal_mixture_k.stan

.R            https://github.com/stan-dev/stan/blob/master/src/models/basic_estimators/normal-mixture_k-sim.R

In this location, the "normal-mixture_k-sim.R" file has a typo in the last line:

           fit <- stan(file="normal_mixture_k.stan", data=("K","N","y"), iter=500, chains=1, init=0);

It should be:

           fit <- stan(file="normal_mixture_k.stan", data=c("K","N","y"), iter=500, chains=1, init=0);

I also tried chains=4, with interesting non-identifiability results - or, if the term "non-identifiable" is not accurate, at least the three components across chains are inter-changed, so while print(fit) with chains=1 gives accurate results, print(fit) with chains = 4 does not, although I imagine each chain gives sensible results (not checked yet).

[Ben Goodrich]

On Saturday, April 13, 2013 6:50:59 PM UTC-4, Steve wrote:

It's very helpful to have the examples in .stan and .R files. Thanks!

You can execute any (working) example model from R with

library(rstan)
fit <- stan_demo() # to see all examples
fit <- stan_demo("normal_mixture_k") # to do a particular example

except that the last line doesn't work due to the typo you found. If it were working, you could then examine the results or the .stan syntax with

cat(get_stancode(fit))

Ben
 

[Andrew Gelman]

Hi, Ben.  I hadn't heard of this feature so I gave it a try.  First I typed fit <- stan_demo()

and it gave me a long list of 119 models. It prompted me for a selection so I typed 114.  Then this is what happened:

Selection: 114

TRANSLATING MODEL 'nnmf' FROM Stan CODE TO C++ CODE NOW.

COMPILING THE C++ CODE FOR MODEL 'nnmf' NOW.

Error : variable does not exist; processing stage=data initialization; variable name=T; base type=int

failed to create the sampler; sampling not done

[Ben Goodrich]

That one is among the 27 that don't work currently. -- Ben

[Steve]

Thanks Ben - that's much cleaner than using google to find the .stan file.

And is there a way to obtain the R code that called the demon *.stan file from within R?

On Saturday, April 13, 2013 6:50:59 PM UTC-4, Steve wrote:

[Steve]

Meant to type:

Is there a way to obtain the R code that called the demo *.stan file from within R?

[Ben Goodrich]

Not that easily. You can do

MODELS_HOME <- file.path(system.file('include', package = 'rstan'), "stansrc", "models")
R_FILES <- dir(MODELS_HOME, pattern = "R$", recursive = TRUE, full.names = TRUE)
R_FILES

to list all of the .R files for the included examples.

Ben

[Andrew Gelman]

Ben

Once all of them work, please let me know and I'll blog it.  This seems like an excellent way for R users to acquaint themselves with Stan!

A

[Bob Carpenter]

Running all the demos sounds great.

I think it'd be easier on users if we don't include
models until they work. At the very least, we should
print out an error message that they can understand
so they don't try to fix something we know is broken.

- Bob

[Bob Carpenter]

On 4/13/13 6:50 PM, Steve wrote:
> It's very helpful to have the examples in .stan and .R files. Thanks!

We've been meaning to wrap these up to make them
easier for people to browse. I have a LaTeX command
to dump out all their source, but it's a bit of
a mess (the source, not the LaTeX command), so I
keep hoping to clean up the models first (both for
line length so they'll fit and for vectorization and
other efficiency issues).

> I found them on github:
>
> .stan https://github.com/stan-dev/stan/blob/master/src/models/basic_estimators/normal_mixture_k.stan
> .R https://github.com/stan-dev/stan/blob/master/src/models/basic_estimators/normal-mixture_k-sim.R
>
> In this location, the "normal-mixture_k-sim.R" file has a typo in the last line:
>
> fit <- stan(file="normal_mixture_k.stan", data=("K","N","y"), iter=500, chains=1, init=0);
>
> It should be:
>
> fit <- stan(file="normal_mixture_k.stan", data=c("K","N","y"), iter=500, chains=1, init=0);

Thanks, I just fixed that.

And now we're back to the chains=1 situation again,
which Andrew doesn't like.

> I also tried chains=4, with interesting non-identifiability results - or, if the term "non-identifiable" is not
> accurate, at least the three components across chains are inter-changed, so while print(fit) with chains=1 gives
> accurate results, print(fit) with chains = 4 does not, although I imagine each chain gives sensible results (not checked
> yet).

Yes, "non-identifiable" is the right term. We've discussed
the non-identifiability of mixture models here on the list
and in the manual in the chapter on mixture models.

When I've run it, they've gotten the same results up to
swapping of indices. Alas, we don't have a good way of
running things like R-hat diagnostics in this case.

- Bob

[Ben Goodrich]

On Monday, April 15, 2013 12:08:05 AM UTC-4, Bob Carpenter wrote:

Running all the demos sounds great.

I think it'd be easier on users if we don't include
models until they work.  

There's that. But in many cases, the model is viable it just has some arbitrarily named R file. We need to always be following the same conventions that we do for the bugs_examples everywhere under src/models/ in the sense of having foo.data.R,  foo.init.R, and foo.stan.

Ben

[Bill Harris]

Bob,

Thanks!  There's lots I want to explore here.

Do you have any more words about as.mcmc.list()?  I can't find it, and I am running 1.3.0.

I also really like the idea of stan_demo(), but I must keep hitting the 27 examples that don't yet work. :-)  I routinely get

> fit <- stan_demo()

Loading Tcl/Tk interface ... done

TRANSLATING MODEL 'regression' FROM Stan CODE TO C++ CODE NOW.

COMPILING THE C++ CODE FOR MODEL 'regression' NOW.

Error : variable does not exist; processing stage=data initialization; variable name=N; base type=int

failed to create the sampler; sampling not done

That was for linear-regression/regression.stan.

Can you provide the name of a demo that should work, so I can figure out what I'm doing wrong?  Alternatively, if you know what I'm doing wrong, let me know.  (I am imagining that each demo is complete with data.  I checked N and found it equal to 1000, even though I don't think I saw N in str(stanresult.)

Bill

[Ben Goodrich]

Most of the demos that originated with BUGS work.

Ben

[Ben Goodrich]

On Monday, April 15, 2013 10:11:38 AM UTC-4, Bill Harris wrote:

Do you have any more words about as.mcmc.list()?  I can't find it, and I am running 1.3.0.

That method didn't get exported, so for now you would have to prefix it:

library(rstan)
dogs <- stan_demo("dogs")
ml <- rstan:::as.mcmc.list(dogs)
library(coda)
summary(ml) # or whatever from coda

Ben

 

[Kyle Foreman]

I've found that my models which used vectors for data in count models break when upgrading from 1.2.0 to 1.3.0.

So I've had to change

data {

   int N;

   vector[N] y;

}

...

model {

   y ~ poisson_log(log_mu);

}

to 

data {

   int N;

   int y[N];

}

...

model {

   y ~ poisson_log(log_mu);

}

Seems like a logical change since vectors are real-valued instead of integers, just thought I'd point it out in case others run into similar backwards compatibility issues.

[Bob Carpenter]

Thanks for pointing this out. We should've mentioned
this change in the release notes.

This is actually a bug fix, not a bug! We always
intended data for Poisson to be constrained to
integers. That's how Poisson was always documented,
but an unintended function declaration made it legal
in earlier code.

- Bob

[Bill Harris]

On Monday, April 15, 2013 7:36:59 AM UTC-7, Ben Goodrich wrote:

Most of the demos that originated with BUGS work.

Thanks, Ben.  I just updated RStan to 1.3.0 on an XP 64 machine running R 2.15.3, and I decided to test that out.  Anything I tried failed, and even a variant of a model that Bob C. posted not too long ago and that ran on my Linux box under 1.3.0 fails here.  FWIW, I have run RStan code successfully on this machine around March 18, at least.

Here's the start of the output:

> standemos <- stan_demo(22)

TRANSLATING MODEL 'dogs' FROM Stan CODE TO C++ CODE NOW.

COMPILING THE C++ CODE FOR MODEL 'dogs' NOW.

cygwin warning:

  MS-DOS style path detected: c:/R/R-215~1.3/etc/x64/Makeconf

  Preferred POSIX equivalent is: /cygdrive/c/R/R-215~1.3/etc/x64/Makeconf

  CYGWIN environment variable option "nodosfilewarning" turns off this warning.

  Consult the user's guide for more details about POSIX paths:

    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

In file included from C:/R/library/rstan/include/rstan/rstaninc.hpp:3:0,

                 from file244a37f1f.cpp:6:

C:/R/library/rstan/include/rstan/stan_fit.hpp: In member function 'SEXPREC* rstan::stan_fit<Model, RNG>::constrain_pars(SEXP) [with Model = model24476a81aad_dogs_namespace::model24476a81aad_dogs, RNG = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >, SEXP = SEXPREC*]':

file244a37f1f.cpp:338:114:   instantiated from here

C:/R/library/rstan/include/rstan/stan_fit.hpp:834:7: error: no matching function for call to 'model24476a81aad_dogs_namespace::model24476a81aad_dogs::write_array(boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >&, std::vector<double>&, std::vector<int>&, std::vector<double>&)'

C:/R/library/rstan/include/rstan/stan_fit.hpp:834:7: note: candidate is:

file244a37f1f.cpp:212:10: note: void model24476a81aad_dogs_namespace::model24476a81aad_dogs::write_array(std::vector<double>&, std::vector<int>&, std::vector<double>&, std::ostream*)

file244a37f1f.cpp:212:10: note:   no known conversion for argument 1 from 'boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >' to 'std::vector<double>&'

C:/R/library/rstan/include/rstan/stan_fit.hpp: In function 'int rstan::{anonymous}::sampler_command(rstan::stan_args&, Model&, Rcpp::List&, const std::vector<long long unsigned int>&, const std::vector<std::basic_string<char> >&, RNG&) [with Model = model24476a81aad_dogs_namespace::model24476a81aad_dogs, RNG = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >, Rcpp::List = Rcpp::Vector<19>]':

C:/R/library/rstan/include/rstan/stan_fit.hpp:912:7:   instantiated from 'SEXPREC* rstan::stan_fit<Model, RNG>::call_sampler(SEXP) [with Model = model24476a81aad_dogs_namespace::model24476a81aad_dogs, RNG = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >, SEXP = SEXPREC*]'

file244a37f1f.cpp:316:114:   instantiated from here

If you want, I can provide more, but it's about 450 lines long.  It ends with

339:     .method("num_pars_unconstrained", 

340:             &rstan::stan_fit<model24476a81aad_dogs_namespace::model24476a81aad_dogs, boost::random::ecuyer1988>::num_pars_unconstrained)

341:     ;

342: } 

343: 

344: // declarations

345: extern "C" {

346: SEXP file244a37f1f( ) ;

347: }

348: 

349: // definition

350: 

351: SEXP file244a37f1f(  ){

352:  return Rcpp::wrap("dogs");

353: }

354: 

355: 

Error in compileCode(f, code, language = language, verbose = verbose) : 

  Compilation ERROR, function(s)/method(s) not created! cygwin warning:

  MS-DOS style path detected: c:/R/R-215~1.3/etc/x64/Makeconf

  Preferred POSIX equivalent is: /cygdrive/c/R/R-215~1.3/etc/x64/Makeconf

  CYGWIN environment variable option "nodosfilewarning" turns off this warning.

  Consult the user's guide for more details about POSIX paths:

    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

In file included from C:/R/library/rstan/include/rstan/rstaninc.hpp:3:0,

                 from file244a37f1f.cpp:6:

C:/R/library/rstan/include/rstan/stan_fit.hpp: In member function 'SEXPREC* rstan::stan_fit<Model, RNG>::constrain_pars(SEXP) [with Model = model24476a81aad_dogs_namespace::model24476a81aad_dogs, RNG = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >, SEXP = SEXPREC*]':

file244a37f1f.cpp:338:114:   instant

In addition: Warning message:

running command 'c:/R/R-2.15.3/bin/x64/R CMD SHLIB file244a37f1f.cpp 2> file244a37f1f.cpp.err.txt' had status 1 

I'm pretty sure it's running cpp 4.5.3 from cygwin.  I also presume the error has to do with configuring the compiler.  I am running RStan in ESS 12.09-2 on Emacs 24.2.1.

Do you have any obvious suggestions from this trace?  Is there anything I can provide that would be useful?

Thanks,

Bill

[Ben Goodrich]

On Wednesday, April 17, 2013 8:35:56 PM UTC-4, Bill Harris wrote:

Do you have any obvious suggestions from this trace?  Is there anything I can provide that would be useful?

Can you still do Hello World?

https://code.google.com/p/stan/wiki/RStanGettingStarted#C++_compiler

Ben

 

[Bill Harris]

Ben,

Yes:

> library(inline)

> library(Rcpp)

> src <- '

+ std::vector<std::string> s;

+ s.push_back("hello");

+ s.push_back("world");

+ return Rcpp::wrap(s);

+ '

> hellofun <- cxxfunction(body=src,includes='', plugin='Rcpp',verbose=FALSE)

cygwin warning:

  MS-DOS style path detected: c:/R/R-215~1.3/etc/x64/Makeconf

  Preferred POSIX equivalent is: /cygdrive/c/R/R-215~1.3/etc/x64/Makeconf

  CYGWIN environment variable option "nodosfilewarning" turns off this warning.

  Consult the user's guide for more details about POSIX paths:

    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

> cat(hellofun(),'\n')

hello world  

standemos <- stan_demo(22) still fails.

As another check, I tried a model Bob C. helped me build:

K <- 3; 

N1 <- 500; 

N2 <- 300; 

N3 <- 200;

N <- N1 + N2 + N3; 

mu1 <- -2.0; 

mu2 <- 0.5; 

mu3 <- 3.5; 

sigma1 <- 1.0; 

sigma2 <- 0.5; 

sigma3 <- 2; 

y <- c(rnorm(N1,mu1,sigma1),rnorm(N2,mu2,sigma2),rnorm(N3,mu3,sigma3)); 

bobcmodel <- '

data { 

   int<lower=1> K; 

   int<lower=1> N; 

   real y[N]; 

} 

parameters { 

   simplex[K] theta; 

   real mu[K]; 

   real<lower=0,upper=10> sigma[K]; 

} 

model { 

   real ps[K]; 

   mu ~ normal(0,10); 

   for (n in 1:N) { 

     for (k in 1:K) 

       ps[k] <- log(theta[k]) 

                + normal_log(y[n],mu[k],sigma[k]); 

     lp__ <- lp__ + log_sum_exp(ps); 

   } 

}

'

library('rstan')

fit <- stan(model_code = bobcmodel, data = list(K=K,N=N,y=y),iter=500, seed = 401, chains=1, init=0);

and that fails, too: 

source('bobc.R')

Loading required package: Rcpp

Loading required package: inline

Loading required package: stats4

rstan (Version 1.3.0, packaged: 2013-04-12 21:12:02 UTC, GitRev: f57455593d14)

TRANSLATING MODEL 'bobcmodel' FROM Stan CODE TO C++ CODE NOW.

COMPILING THE C++ CODE FOR MODEL 'bobcmodel' NOW.

cygwin warning:

  MS-DOS style path detected: c:/R/R-215~1.3/etc/x64/Makeconf

  Preferred POSIX equivalent is: /cygdrive/c/R/R-215~1.3/etc/x64/Makeconf

  CYGWIN environment variable option "nodosfilewarning" turns off this warning.

  Consult the user's guide for more details about POSIX paths:

    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

In file included from C:/R/library/rstan/include/rstan/rstaninc.hpp:3:0,

                 from fileebc322e42d1.cpp:6:

C:/R/library/rstan/include/rstan/stan_fit.hpp: In member function 'SEXPREC* rstan::stan_fit<Model, RNG>::constrain_pars(SEXP) [with Model = modelebc2d697bb_bobcmodel_namespace::modelebc2d697bb_bobcmodel, RNG = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014u, 0u, 2147483563u>, boost::random::linear_congruential_engine<unsigned int, 40692u, 0u, 2147483399u> >, SEXP = SEXPREC*]':

fileebc322e42d1.cpp:351:122:   instantiated from here

:-(

Bill

[Bill Harris]

On Thursday, April 18, 2013 12:35:22 PM UTC-7, Bill Harris wrote:

On Wednesday, April 17, 2013 5:52:26 PM UTC-7, Ben Goodrich wrote:

On Wednesday, April 17, 2013 8:35:56 PM UTC-4, Bill Harris wrote:

Do you have any obvious suggestions from this trace?  Is there anything I can provide that would be useful?

Can you still do Hello World?

https://code.google.com/p/stan/wiki/RStanGettingStarted#C++_compiler

Ben,

Yes:

Incidentally, I thought the following code used to return something after the last command:

> library(rstan)

> set_cppo("fast")

mode fast without NDEBUG for compiling C++ code has been set already

> get_cppo()

but it returns nothing.  Is that a clue?

I decided to prove to allI had the right version loaded, and so I restarted R and captured the following:

R version 2.15.3 (2013-03-01) -- "Security Blanket"

Copyright (C) 2013 The R Foundation for Statistical Computing

ISBN 3-900051-07-0

Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.

You are welcome to redistribute it under certain conditions.

Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.

Type 'contributors()' for more information and

'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or

'help.start()' for an HTML browser interface to help.

Type 'q()' to quit R.

[Previously saved workspace restored]

> > options(chmhelp=FALSE, help_type="text")

> options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient.exe', show.error.locations=TRUE)

> library(rstan)

Loading required package: Rcpp

Loading required package: inline

Loading required package: stats4

rstan (Version 1.3.0, packaged: 2013-04-12 21:12:02 UTC, GitRev: f57455593d14)

> stan_version()

[1] "1.2.0" 

The last line of the output from library(rstan) together with the output of stan_version() confuse me.  Is it possible that stan_version() didn't get updated, or is it possible that I have a borked installation?  More clues?  More questions?

Bill

[Jiqiang Guo]

On Thu, Apr 18, 2013 at 4:18 PM, Bill Harris <bill_...@facilitatedsystems.com> wrote:

The last line of the output from library(rstan) together with the output of stan_version() confuse me.  Is it possible that stan_version() didn't get updated, or is it possible that I have a borked installation?

I think you have just have a broken version of rstan.  This happens on windows and that why in the rstan getting started, we have remove rstan before installing a new version of rstan, and then restart R.  So make sure you have removed an older version of rstan while rstan is not loaded before installing a new one. 

--

Jiqiang 

[Bill Harris]

On Thursday, April 18, 2013 1:52:29 PM UTC-7, Jiqiang Guo wrote:

I think you have just have a broken version of rstan.  This happens on windows and that why in the rstan getting started, we have remove rstan before installing a new version of rstan, and then restart R.  So make sure you have removed an older version of rstan while rstan is not loaded before installing a new one. 

--

Jiqiang 

Thanks, Jiqiang.  I was sure I had done as you described, but I had missed the part about removing the older version when rstan is not loaded.  I verified that by noticing that the installation process couldn't copy the new rstan.dll into place; I still had the 1.2.0 version.  I quit all R ESS sessions and started over, and now it works.

It's probably obvious to everyone else, but it wouldn't hurt to add that comment to https://code.google.com/p/stan/wiki/RStanGettingStarted.  

Bill 

[Bob Carpenter]

On 4/18/13 5:22 PM, Bill Harris wrote:
...

> Thanks, Jiqiang. I was sure I had done as you described, but I had missed the part about removing the older version
> when rstan is not loaded.

What do you mean when rstan is not loaded?

Jiqiang -- Are there different instructions for removing
rstan depending on whether or not the lib is loaded?

If so, we should definitely put this in the doc as Bill
suggests.

I think we could also use a big checklist for the
install that we could point people to. I think the users
get lost in the text, because despite the fact that the
"uninstall previous versions" is the very first thing
we say in text and then in code, people manage to miss
it. (I have a lot of sympathy for users here as I've
spent plenty of time frustrated by install instructions
I didn't understand or understand how to debug when they
went wrong.)

> I verified that by noticing that the installation process couldn't copy the new rstan.dll
> into place; I still had the 1.2.0 version. I quit all R ESS sessions and started over, and now it works.
>
> It's probably obvious to everyone else, but it wouldn't hurt to add that comment to
> https://code.google.com/p/stan/wiki/RStanGettingStarted.

Jiqiang -- could you take a shot at doing that on the Wiki page
if necessary?

And could you create a checklist for installs that goes step
by step. If you could actually render it as a checkbox, that'd
be awesome, but the markup's probably not rich enough to do it
easily (unless you can find a unicode character for checkbox!).

- Bob

[Bill Harris]

In my case, it finally seemed to work when I did the remove.packages after quitting and restarting R /without/ first executing library(rstan).  I don't think I had needed to do that when upgrading to 1.2.0, and I'm not sure I did that when upgrading on Linux to 1.2.0 or 1.3.0, but it seemed necessary on Windows (or at least on XP 64).

--
You received this message because you are subscribed to the Google Groups "stan users mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

[Bill Harris]

Incidentally, I was puzzled that R asked for a CRAN mirror when I issued the install.packages() command even after I had entered the options() statement.  I can understand that install.packages() might not know it doesn't need CRAN in this case, but I don't recall that prompt in previous rstan upgrades.  

Pr(it's my memory, not the installation process) ~ 0.5

Bill

[Jiqiang Guo]

Please see comments below.  Jiqiang

On Thu, Apr 18, 2013 at 5:47 PM, Bob Carpenter <ca...@alias-i.com> wrote:

On 4/18/13 5:22 PM, Bill Harris wrote:
...

Thanks, Jiqiang.  I was sure I had done as you described, but I had missed the part about removing the older version
when rstan is not loaded.

What do you mean when rstan is not loaded?

Before "library(rstan)" is called in R.  I thought if it is loaded, some files cannot be removed during removing old packages and cannot be overwritten by installing new package.  These things are not necessary.  I do not have the very idea when remove.package and install.package are not fully doing what they are supposed to do.  

 

Jiqiang -- Are there different instructions for removing
rstan depending on whether or not the lib is loaded?

No.  Ideally, it is not required (even the part of removing rstan of older version).  

If so, we should definitely put this in the doc as Bill
suggests.

I would add a few worlds to be more conservative, but increase the success probability.  

I think we could also use a big checklist for the
install that we could point people to.  I think the users
get lost in the text, because despite the fact that the
"uninstall previous versions" is the very first thing
we say in text and then in code, people manage to miss
it.  (I have a lot of sympathy for users here as I've
spent plenty of time frustrated by install instructions
I didn't understand or understand how to debug when they
went wrong.)

I verified that by noticing that the installation process couldn't copy the new rstan.dll
into place; I still had the 1.2.0 version.  I quit all R ESS sessions and started over, and now it works.

It's probably obvious to everyone else, but it wouldn't hurt to add that comment to
https://code.google.com/p/stan/wiki/RStanGettingStarted.

Jiqiang -- could you take a shot at doing that on the Wiki page
if necessary?

And could you create a checklist for installs that goes step
by step.  If you could actually render it as a checkbox, that'd
be awesome, but the markup's probably not rich enough to do it
easily (unless you can find a unicode character for checkbox!).

 

I will try.  

[Jiqiang Guo]

On Thu, Apr 18, 2013 at 4:18 PM, Bill Harris <bill_...@facilitatedsystems.com> wrote:

> library(rstan)

> set_cppo("fast")

mode fast without NDEBUG for compiling C++ code has been set already

> get_cppo()

but it returns nothing.  Is that a clue?

Thanks for pointing this out.  The returned value of get_cppo() is invisible.  I guess I should change it to visible for next release. 

> a <- get_cppo()

> a

$mode

[1] "fast"

$NDEBUG

[1] TRUE

$DEBUG

[1] FALSE

--

Jiqiang

[Bill Harris]

Jiqiang Guo <guo...@gmail.com> writes:

>> a <- get_cppo()
>> a
> $mode
> [1] "fast"
>
> $NDEBUG
> [1] TRUE
>
> $DEBUG
> [1] FALSE

Jiqiang,

Thanks!

Bill
--
Bill Harris
Facilitated Systems
http://makingsense.facilitatedsystems.com/

[Jeff]

Hi,

Please let me know if I'm posting this in the wrong place,

I've tried installing rstan on 3.0.0 with no success, after following the instructions on https://code.google.com/p/stan/wiki/RStanGettingStarted. I'm able to get the Rcpp to work, and the problem seems to occur during the rstan installation itself.

Attached is the code that R outputs during the rstan installation, my sessionInfo(), and what the Rcpp says using the Hello world example (it has a cygwin warning but I guess this is to do with Rtools?), and the info on the g++ compiler I'm using,

Also, I have previously installed cygwin, but uninstalled it after I had issues installing rstan to see if that might fix it but with no luck. I have codeblocks currently installed on my computer, but have removed the directory to the compilers in codeblocks from PATH (because it has g++.exe and gcc.exe) so R should be using the compiler in Rtools (and this seems to be the case after typing  system("g++ -v")),

Any help would greatly be appreciated, Jeff

[Ben Goodrich]

On Saturday, April 20, 2013 8:47:56 PM UTC-4, Jeff wrote:

Any help would greatly be appreciated, Jeff

I suspect you have some stuff in $HOME/.R/Makevars or a similar file that gets read at startup. Several flags --- -m64, -mtune=core2, and -g --- are getting appended somehow, which causes the parser to fail to compile. If you can get those removed, at least temporarily, rstan should install fine.

Ben

[Jeff]

I modified Makevars and makeconf (in C:\R-3.0.0\etc\x64) to get rid of the extra flags, and after that the installation process hit an error with:

g++ -shared -s -static-libgcc -o rstan.dll tmp.def stanc.o chains.o misc.o gm__ast_def.o gm__grammars__expression_grammar_inst.o gm__grammars__program_grammar_inst.o gm__grammars__statement_2_grammar_inst.o gm__grammars__statement_grammar_inst.o gm__grammars__term_grammar_inst.o gm__grammars__var_deccls_grammar_inst.o gm__grammars__whitespace_grammar_inst.o C:/R-30~1.0/library/Rcpp/lib/x64/libRcpp.a -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/R-30~1.0/bin/x64 -lR
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: skipping incompatible C:/R-30~1.0/bin/x64/R.dll when searching for -lR
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: skipping incompatible C:/R-30~1.0/bin/x64/R.dll when searching for -lR
c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lR
collect2: ld returned 1 exit status

but I was able to fix this by modifying the makeconf file and removing -lR.

After re-trying the installation and getting past this line, my R console started getting flooded with error messages about a "symbol not defined", and "undefined reference to" errors.

I've tried using capture.output and sink to save all the errors to a .txt, but haven't had much luck. I've attached the last errors in the console after it finished returning errors.

Cheers, Jeff

[Ben Goodrich]

On Sunday, April 21, 2013 9:44:08 AM UTC-4, Jeff wrote:

After re-trying the installation and getting past this line, my R console started getting flooded with error messages about a "symbol not defined", and "undefined reference to" errors.

I've tried using capture.output and sink to save all the errors to a .txt, but haven't had much luck. I've attached the last errors in the console after it finished returning errors.

Can you post what is left of your Makevars, makeconf, etc. files? For some reason, the linker seems to be failing.

Ben

[Jeff]

Sure, the only files I've changed are Makeconf and Makevars (attached),

Thank you very much for your help with this!

Jeff

[Z. Su]

I had got a similar problem on Windows XP when installing rstan:

Fatal error: can't close gm__grammars__statement_grammar_inst.o: File too big
make: *** [gm__grammars__statement_grammar_inst.o] Error 1
ERROR: compilation failed for package 'rstan'
* removing 'C:/R-3.0.0/library/rstan'

But I installed rstan successfully after I changed Makevar CXXFLAGS 
to the following (I guess -O0 caused the problem):
CXXFLAGS = -O3 -Wall $(DEBUGFLAG) -mtune=core2 

ZS

[Bob Carpenter]

On 4/22/13 10:59 AM, Z. Su wrote:
> I had got a similar problem on Windows XP when installing rstan:
>
> Fatal error: can't close gm__grammars__statement_grammar_inst.o: File too big
> make: *** [gm__grammars__statement_grammar_inst.o] Error 1
> ERROR: compilation failed for package 'rstan'
> * removing 'C:/R-3.0.0/library/rstan'
>
> But I installed rstan successfully after I changed Makevar CXXFLAGS
> to the following (I guess -O0 caused the problem):
> CXXFLAGS = -O3 -Wall $(DEBUGFLAG) -mtune=core2

Thanks for the report with the relevant details.

Can we make bin/stanc compile at -O0 and everything
else at -O3?

We've had this problem with our Windows test machine (running
out of memory). Seems like the Windows toolchain isn't
as well-behaved memory-wise as the equivalent Mac/Linux tools.
We've had problems primarily with the GNU assembler.

- Bob

[Jeff]

Thanks! I think I've managed to install it now,

I tried Z. Su's suggestion of using -O3 in Makevars, and after some trial and erorr-ing worked out that the .cpp files need to be compiled with a -m64 flag, and I need to have -l R instead of -lR in order for this line to work:

g++ -m64 -shared -static-libgcc -o rstan.dll tmp.def stanc.o chains.o misc.o gm__ast_def.o gm__grammars__expression_grammar_inst.o gm__grammars__program_grammar_inst.o gm__grammars__statement_2_grammar_inst.o gm__grammars__statement_grammar_inst.o gm__grammars__term_grammar_inst.o gm__grammars__var_deccls_grammar_inst.o gm__grammars__whitespace_grammar_inst.o C:/R-30~1.0/library/Rcpp/lib/x64/libRcpp.a -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/R-30~1.0/bin/x64 -l R

I then added the -g and -mtune=core2 back into /.R/Makevars to see if they were causing any issues, and they didn't seem to cause any additional warnings to appear so I've left them in for the moment,

I've managed to install rstan and run the schools_code example, but there were a few warnings raised during this. I've attatched a .txt with the warning messages that appear in the console during the installation and test run, could someone please check that the warnings are safe to ignore?

Cheers, Jeff

[Ben Goodrich]

On Tuesday, April 23, 2013 1:27:40 AM UTC-4, Jeff wrote:

I've managed to install rstan and run the schools_code example, but there were a few warnings raised during this. I've attatched a .txt with the warning messages that appear in the console during the installation and test run, could someone please check that the warnings are safe to ignore?

Those warnings are not specific to your setup and are ignorable. In general, the -Wunused warnings are less relevant for a library where it is hard to know in advance what functions a user may or may not actually be using in a particular model.

Ben
 

[Jeff]

Awesome, thanks!

Jeff