telling stan to save things

[Andrew Gelman]

I have a stan model with parameters real mu and real theta3[J3]. I want to create the foliowing:

for (j in 1:J3)
theta3_adj[j] <- theta3[j] - mu;

This seems to work fine, as long as I define theta3_adj within the "model" statement (not the "parameters"). That's fine. But then when stan is done, it does not seem to have saved theta3_adj. That's a bummer cos the only reason I created theta3_adj was to save it!

Also, I tried the following:

for (j in 1:J3)
theta3_dif[j] <- theta3[j] - mean(theta3);

But it didn't work.

A

[Jiqiang Guo]

In this case, you need to have theta3_adj in the transformed parameters block. 

An example:  https://code.google.com/p/stan/source/browse/src/models/bugs_examples/vol1/blocker/blocker.stan 

--

Jiqiang 

[Andrew Gelman]

Given that we have the Bugs models conveniently on the website, I retract my request to have them all in a pdf file.  I think what we need to do is to have a very clean public main page, that points to the following things:

- Instructions for setting up Stan

- Instructions for setting up Stan from R

- Stan manual

- Bugs examples

- Stan mailing lists

The current Stan homepage is just full of stuff but not particualrly user-oriented.

Also, do we want a stan mainpage?  I checked and "mcstan.org" is available.  Or we could just put it somewhere like http://www.stat.columbia.edu/~gelman/stan/

The googlecode page is fine but I think it would help to have a super-clean homepage.

[Andrew Gelman]

J

I couldn't get transformed_parameters to work.  I tried in my model and failed, then I tried in the 8 schools and failed; see below.

A

schools.code <- '

  data {

    int[0,] J; // number of schools 

    real y[J]; // estimated treatment effects

    real[0,] sigma_y[J]; // s.e. of effect estimates 

  } 

  parameters {

    real theta[J]; 

    real mu; 

    real[0,] tau; 

  } 

  transformed_parameters {

    real a;

    a <- mu + 3;

  }

  model {

    theta ~ normal(mu, tau); 

    y ~ normal(theta, sigma_y);

  } 

'

dat <- list(J = 8, 

            y = c(28,  8, -3,  7, -1,  1, 18, 12),

            sigma_y = c(15, 10, 16, 11,  9, 11, 10, 18))

And the result:

> fit <- stan(model.code = schools.code, data = dat, 

+             n.iter = 2012, n.chains = 4)

COMPILING MODEL 'anon_model' FROM Stan CODE TO C++ CODE NOW.

Error in stanc(model.code, model.name) : 

  Failed to parse Stan model 'anon_model' and error message provided as:

LOCATION:  file=input; line=12, column=3

  transformed_parameters {

  ^-- here

DIAGNOSTIC(S) FROM PARSER:

Parser expecting: <model declaration>

>

On Aug 10, 2012, at 4:10 PM, Jiqiang Guo wrote:

[Daniel Lee]

Try "transformed parameters" as two words, no underscore.

[Jiqiang Guo]

No underscore between transformed and parameters. 

Jiqiang 

On Fri, Aug 10, 2012 at 10:29 AM, Andrew Gelman <gel...@stat.columbia.edu> wrote:

  transformed_parameters

[Andrew Gelman]

Fuck.  I was mesmerized by all the underscores I needed to add to my variable names to replace the dots.

[Bob Carpenter]

On 8/10/12 10:23 AM, Andrew Gelman wrote:
> Given that we have the Bugs models conveniently on the website, I retract my request to have them all in a pdf file. I
> think what we need to do is to have a very clean public main page, that points to the following things:

>

> The current Stan homepage is just full of stuff but not particualrly user-oriented.

> The googlecode page is fine but I think it would help to have a super-clean homepage.

I agree that we need to make this easier for users
who aren't used to open-source code projects.

Maybe you want a separate Stan and RStan page. Otherwise,
things are going to get complicated if we have all of our
interfaces (we have R for some statisticians, but have toyed
with doing stata, too; we need Python for the hackers and MATLAB
for the engineers/coputer scientists).

So the Stan home page could just point to a separate
"using Stan from R" sub page.

The things I thought were critical are in the right column
under "Stan". Do you think we can remove any of that
to make it cleaner?

I'd be happy getting rid of "how to cite Stan", which is up
there because Andrew wanted it in the first place! I also
don't think we need the blog links.

We could move everything one level down and just have
links. So "Get Involved" could point to a "Get Involved"
page, etc. That makes it cleaner at the expense of requiring
more nav clicks by the user. Ditto for "Contact", but that
may not be enough of a name to indicate its contents for those
not used to open-source projects.

If you want clean, you also need to REMOVE things.

Here's where these things are now and what I think
we could add:

> - Instructions for setting up Stan

In the Stan User's Guide. Need to be pulled up.

> - Instructions for setting up Stan from R

In the "RStan Getting Started Guide". Maybe we should
change the name to "RStan Installation and Getting Started Guide"?
Or should we have two links? A whole sub-heading about
installation?

> - Stan manual

There's a clear link under Documentation. At least it seems
clear to me.

> - Bugs examples

That's not on the home page.

> - Stan mailing lists

These are listed under "Groups" on the links page, where they
always are for Google Code projects (not that R/BUGS users
would realize that), but they're also under the "Contact" heading
on the right.

- Bob


>
> Also, do we want a stan mainpage? I checked and "mcstan.org <http://mcstan.org>" is available. Or we could just put it
> somewhere like http://www.stat.columbia.edu/~gelman/stan/
>

>
>
>

[Andrew Gelman]

My proposal was to keep the Stan googlecode page as is (or change it to the extent that Bob wants) and to create a new homepage (not a googlecode page) with the 5 or so links that are really important, including the link to the googlecode page for people who want more.
A

[Bob Carpenter]

I'm happy to create a Stan home page.

URL:

I like "mc-stan.org". Is everyone else OK with that?

We'll want mc-stan.com, too, so it can forward.

How do I create this and bill it to the project? Who
should the registrar be?


MAIL:

Then we can set up mail for various features at mc-stan.org
and make sure they get routed to the right person. As of
now, we're using mc-sta...@gmail.com as the single e-mail
contact that forwards to me and Daniel. (We can set it up
to forward to a wider audience if anyone else wants in.)


HOME PAGE:

I can layout the HTML, but the issue is what should be
on the page. Andrew suggests 5 or so lines that are
really important. That means we're going to have to
do some re-org and re-thinking.

With a separate home page, the "Google Code" home page
function changes. Let's think top-down from the Stan
home page. I find the best way to do this is to consider
who might be visiting it and what they might want.

At the very least, I see users coming in for the
latest C++/command-line or R code, wanting to know
where to report bugs or contact us via e-mail.

Here's what's there now:

* Description of what Stan is (must be suitable for all users,
or allow quick triage of users to their appropriate 2nd
tier page)

* Status indication of latest version
(perhaps implicit in a link to code, etc.?)

* Link to getting started docs
a. C++
b. command-line
c. RStan

* Links to manuals
a. C++ API
b. Modeling Language + Command Line
c. RStan

* Links to code downloads
a. latest RStan
b. latest C++/command-line Stan

* Links to mailing lists
a. Stan Users' Group
b. Stan Developers' Group
c. Stan Announce
d. Stan BuildBot Status

* License Info
a. Stan (BSD)
b. RStan (GPL)
c. Eigen (LGPL), Boost (Boost License)

* Contact e-mail

* About
a. who wrote it
b. who funded it

* Links for Issue Tracking
a. reporting BUGS
b. suggesting features

* Get Involved
a. contribute patches or more code
b. contribute a model

* How to Cite Stan

Things Andrew suggested adding:

* Link to BUGS models

Things people have suggested removing:

:-)

- Bob

[Ben Goodrich]

On Friday, August 10, 2012 2:26:44 PM UTC-4, Bob Carpenter wrote:

*  License Info
     a.  Stan (BSD)
     b.  RStan (GPL)
     c.  Eigen (LGPL), Boost (Boost License)

OT, but the very latest Eigen (3.1.1) is now MPL2.

http://eigen.tuxfamily.org/index.php?title=Main_Page#License

I don't think that is a problem for Stan or RStan but perhaps we should bump Eigen now and change the references to LGPL.

Ben

[Bob Carpenter]

RStan is using RcppEigen. The RcppEigen CRAN page's
NEWS as of 2012-06-26 indicates Eigen 3.1.0.

If we upgrade Stan's version of Eigen to 3.1.1, we
have to support multiple versions of Eigen.

As I've said before, I would very strongly prefer it if
we could distribute our own version of Eigen with RStan.
I believe the main issue before was size for CRAN, but
if we're skipping CRAN. So does anyone object to including
the same Eigen in RStan as we use in C++ Stan?

At least this compatibility issue is backward. In
RcppEigen version 0.2.0 they were using Eigen version
3.1.0-alpha2. I'd rather not have to support prototypes.
Maybe things will settle down RcppEigen ever gets to
version 1? Or is this just another CS/stats difference
(numbering versions from 1/0 and arrays from 0/1)?

- Bob

[Ben Goodrich]

If the plan is to avoid CRAN, then RStan might as well drop the dependency on RcppEigen and provide the supported Eigen headers in rstan/inst/include . I am not sure that avoiding CRAN is a good idea though. Did I miss a discussion of that?

[Bob Carpenter]

On 8/10/12 3:03 PM, Ben Goodrich wrote:
> If the plan is to avoid CRAN, then RStan might as well drop the dependency on RcppEigen and provide the supported Eigen
> headers in rstan/inst/include . I am not sure that avoiding CRAN is a good idea though. Did I miss a discussion of that?

I don't think so. I may have misunderstood and
the current not-from-CRAN install instructions may
only be temporary.

But if we can get our version of Boost up on CRAN,
can we also get Eigen up on CRAN? The notes from
Ripley on sizing aren't absolute.

- Bob

[Ben Goodrich]

On Friday, August 10, 2012 3:07:32 PM UTC-4, Bob Carpenter wrote:

On 8/10/12 3:03 PM, Ben Goodrich wrote:
> If the plan is to avoid CRAN, then RStan might as well drop the dependency on RcppEigen and provide the supported Eigen
> headers in rstan/inst/include . I am not sure that avoiding CRAN is a good idea though. Did I miss a discussion of that?

I don't think so.  I may have misunderstood and
the current not-from-CRAN install instructions may
only be temporary.

I thought that was just a beta-testing thing.

But if we can get our version of Boost up on CRAN,
can we also get Eigen up on CRAN?  The notes from
Ripley on sizing aren't absolute.

For Boost, if whatever is on CRAN is not recent enough, my guess is that they would prefer to upgrade their Boost than to have to pay the bandwidth costs of distributing a good chunk of Boost with RStan. For Eigen, I would imagine they would say "just use RcppEigen".

Ben

[Bob Carpenter]

Are they really still moderating CRAN on a case
by case basis? What a load of work for them!

I must've missed that there was a Boost version on
CRAN. CRAN says the boost package is 404 since boost-1.0.0
in 2004:

http://cran.r-project.org/web/packages/boost/index.html

The only other thing I saw was:

http://cran.r-project.org/web/packages/RcppBDT/index.html

which is an Rcpp wrapper around Boost Date/Time that requires
you to include your own Boost headers.

Maybe we could just do that so that we'd be on CRAN
and be able to control the Eigen and Boost versions.

- Bob

[Ben Goodrich]

On Friday, August 10, 2012 4:14:16 PM UTC-4, Bob Carpenter wrote:

Are they really still moderating CRAN on a case
by case basis?    What a load of work for them!

Yes, and yes.
 

I must've missed that there was a Boost version on
CRAN.  CRAN says the boost package is 404 since boost-1.0.0
in 2004:

Mav and I had discussed this on the list. The boost R package is abandoned, but the CRAN servers have some version of Boost on them. Presumably, this is the version of Boost in the Debian testing repository, which is 1.49. Thus, if the version of Boost that CRAN has is sufficient to build stanc (and thus RStan), it is possible to require that a particular version of Boost be available on the system to compile the models.

Conceivably, we could do the same thing with Eigen. Depend on RcppEigen so that the CRAN servers can build RStan but require a particular version of the Eigen headers be available on the system to compile the models.

That is always available as a fallback plan, although it seems confusing to users. There is no law that says we can't also host a giant version of RStan on GoogleCode that has all of Boost and Eigen in rstan/inst/include for people who are unable to follow instructions for how to install Boost and / or Eigen themselves.

I don't know that much about Boost, but I still think it is feasible for (R)Stan to support whatever version of Eigen RcppEigen has at the moment and whatever is the latest stable Eigen on the Eigen website. Most of the time, they won't diverge that much, and if there is something in (R)Stan that works with one but not the other, then we would want to know about it because it is probably a regression.

Ben

[Andrew Gelman]

Hi, Bob.

1. mc-stan.org is good for me.

2. Here's what I would put on the home page:
a. One or two-sentence description of Stan along with the logo
b. Status indication of latest version (e.g., "Latest versions: Stan1.03 released 9 Aug 2012, Rstan 1.1 released 10 Aug 2012")
c. Link to instructions: How to install Stan through R
d. Link to instructions: How to install Stan to run directly
e. Link to Stan manual
f. Link to page with Stan examples
g. For more: link to googlecode page
h. How to join the user group [with a note that info on the developer group is on the googlecode page]

3. I don't think we need most of the other things in your list below. We don't need to link to the Rstan manual, that link can be on the "How to install Stan through R directly" page. We don't need to link to C++ API, that can be on the googlecode page. We don't need to link to the licence info, that can be on the googlecode page. Etc.

I am happy to have the google code page be as crowded as you'd like. But I'd like the homepage to be clean. Users like me would liek the manual, the installation instructions, the examples, and to see whether anything is new. More sophisticated people can go to the googlecode page. Thus, I'm not suggesting to remove any info, I just want to create a clean friendly portal. Right now, I'm in the stan project but I had difficulty finding what I need.

Does that make sense?
A