RStan options

26 views
Skip to first unread message

Bob Carpenter

unread,
Aug 29, 2012, 7:49:10 PM8/29/12
to stan...@googlegroups.com
RStan looks super great. All of the functionality we
wanted is in it and the doc's already pretty clear.

A couple of issues I brought up with Jiqiang, neither of
which is major (both have simple workarounds):

1. Initialization in RStan doesn't take an R function to
call per chain, like R2WinBUGs, but just a list of lists for
each chain. (As well as allowing the all-0 inits and random
inits.)

Workaround: run the function num_chains times and stuff into list.

2. The data can be an environment, but there's no default.
I had thought we'd talked about taking the user's environment.

I think some others (Malecki, Ben?) were objecting to using an
environment at all.

Workaround: run the function with .GlobalEnv or whatever.

- Bob

Andrew Gelman

unread,
Aug 29, 2012, 8:09:45 PM8/29/12
to stan...@googlegroups.com
I don't understand item #1. Can you explain?
> --
>

Ben Goodrich

unread,
Aug 29, 2012, 11:30:17 PM8/29/12
to stan...@googlegroups.com
On Wednesday, August 29, 2012 7:49:12 PM UTC-4, Bob Carpenter wrote:
2.  The data can be an environment, but there's no default.
I had thought we'd talked about taking the user's environment.

I think some others (Malecki, Ben?) were objecting to using an
environment at all.

   Workaround:  run the function with .GlobalEnv or whatever.

I don't think stan() should be hard-coded to evaluate in .GlobalEnv . This can cause correct but unexpected behavior if stan() is being called by some other function. For example,

foo <- function(...) {
  pi <- # something not equal to 3.14ish
  posterior <- stan("my_model.stan", data = list(pi = pi))
  return(posterior)
}

If stan() evaluates in .GlobalEnv, then the pi in data{} block of my_model.stan will be 3.14ish.

What's wrong with just letting R evaluate lexically like it always does?

Ben

Bob Carpenter

unread,
Aug 30, 2012, 12:54:52 AM8/30/12
to stan...@googlegroups.com
from Jiqiang:

> I guess i am not making it clear on the first one.
> It allows init to be a function

Great! I missed that in the doc somehow.

- Bob

Bob Carpenter

unread,
Aug 30, 2012, 1:37:14 AM8/30/12
to stan...@googlegroups.com
Short answer, nothing!

This was a couple of confusions on my part.

One was the R idiom where you don't want to set
a default parameter value other than NULL,
because you may pass data in other ways. Defaults
get confusing when there are optional arguments
that control settings (sort of like for Stan itself's
command-line control of HMC vs. NUTS through interacting
arguments).

My second confusion was about global environments.
I should've replaced ".GlobalEnv or whatever" with
"environment() or whatever". (I only remembered the
.GlobalEnv from something in the mi interface.)

Sorry -- this is just MY lack of fluency in R.
We absolutely don't want to document the R language
as part of our own doc.

Examples of using the idioms should go in a tutorial
user's guide. I wouldn't mind taking a whack at writing
that to force myself to learn R better.

- Bob

Reply all
Reply to author
Forward
0 new messages