RStan status

[Jiqiang Guo]

RStan is done except for polishing up, bug fixes if found, and probably more documentation unless new functionality is needed. 

But there are a couple of issues.

1. I am looking the the effective sample size calculation now.  We need something that works not slow and supports one chain.

2. In stan/gm/ast_def.cpp and probably some other place, 

we have code that writes to standard error output.  R CMD check would report a warning (but not pointing out the exact place) for this. 

In addition, I am thinking of including boost inside RStan now as first I do not think it is easy for users of Windows and Mac (including Andrew)
to install something called boost into the system's header folder.  Second at least on Linux, I could monitor all the file IO, 

for example, for make test-all, so that I could get a list of all boost header files that are opened.  We might be able to downsize

boost header files from 100M to around 20M.  I am not sure this is a good idea and if I have not thought about something important. 

Last, I got rid of the symbol links used before as what works on linux is not working on windows.  So typical `R CMD build (and INSTALL)`

would not work now.  But I have a simple makefile in folder rstan, which could be used to build and install RStan before we could get it on CRAN. 

--

Jiqiang 

[Ben Goodrich]

On Monday, July 23, 2012 8:36:58 PM UTC-4, Jiqiang Guo wrote:

In addition, I am thinking of including boost inside RStan now as first I do not think it is easy for users of Windows and Mac (including Andrew)
to install something called boost into the system's header folder.  Second at least on Linux, I could monitor all the file IO, 

for example, for make test-all, so that I could get a list of all boost header files that are opened.  We might be able to downsize

boost header files from 100M to around 20M.  I am not sure this is a good idea and if I have not thought about something important. 

If I remember correctly, CRAN made Malecki split mrpdata from mrp over 6 MB. So, I would guess they would have a problem with boost no matter how small we make it. I imagine most R users could manage if rstan would offer to open a web browser to http://www.boost.org/users/download/ .
 

Last, I got rid of the symbol links used before as what works on linux is not working on windows.  So typical `R CMD build (and INSTALL)`

would not work now.  But I have a simple makefile in folder rstan, which could be used to build and install RStan before we could get it on CRAN. 

If the makefile route works, that is fine. But the symlink thing should work as well. As long as we do R CMD build rstan on Linux and upload that to CRAN, people who download the source from CRAN will get hard versions of whatever we symlink. It is only a problem for Windows people who download (R)stan from Google code. and try to build from source.

Is there any progress on LinkingTo RcppEigen rather than including the Eigen headers in RStan?

Ben

[Bob Carpenter]

On 7/23/12 8:36 PM, Jiqiang Guo wrote:
> RStan is done except for polishing up, bug fixes if found, and probably more documentation unless new functionality is
> needed.

Great news.

What's the status of the function/package doc
and install instructions? We can test them on Andrew.

> But there are a couple of issues.
> 1. I am looking the the effective sample size calculation now. We need something that works not slow and supports one
> chain.

I'm sure we can fix this. It's probably be
something a profiler will pick up right away.
I'll get back to it after finishing the manual
revision if Daniel doesn't fix it.

I'll post another message about one chain ESS.

> 2. In stan/gm/ast_def.cpp and probably some other place,
> we have code that writes to standard error output. R CMD check would report a warning (but not pointing out the exact
> place) for this.

I find grep -R works really well for normal code.
If there are lots of macros it's pretty useless.

I thought I'd gotten rid of them all, but apparently
not. I'll do that ASAP. We will still have some
command-line programs that write to stdout and stderr.

I'll do that right now.

> In addition, I am thinking of including boost inside RStan now as first I do not think it is easy for users of Windows
> and Mac (including Andrew)

> to install something called boost into the system's header folder.

Difficulty aside, I don't think we want to insist on putting
code in someone's system's header folder! I know, I know
Ben is going to tell me that's how people roll on Linux, but
this kind of global config has led to nothing but compatibility
heartache in my experience.

> Second at least on Linux, I could monitor all the
> file IO,

> for example, for make test-all, so that I could get a list of all boost header files that are opened. We might be able
> to downsize
> boost header files from 100M to around 20M.

Yikes -- I hadn't even realized it unpacked to that
much data. Being code, it compresses nicely.

> I am not sure this is a good idea and if I have not thought about something
> important.

I don't think any of the header includes will depend on which
model gets used. But you'll be surprised just how much of
Boost gets included.

- Bob

[Jiqiang Guo]

On Mon, Jul 23, 2012 at 10:18 PM, Bob Carpenter <ca...@alias-i.com> wrote:

What's the status of the function/package doc
and install instructions?  We can test them on Andrew.

If it is on CRAN, typically we do not have installation instruction.  The package doc are inside the package and 

once the packaged is installed, the user can see inside R.  

I am thinking of writing a simple vignette? 

 

But there are a couple of issues.
1. I am looking the the effective sample size calculation now.  We need something that works not slow and supports one
chain.

I'm sure we can fix this.  It's probably be
something a profiler will pick up right away.
I'll get back to it after finishing the manual
revision if Daniel doesn't fix it.

Sure we can fix.  I profiled a bit and realized we are computing all orders of auto-correlations.   

So definitely when the chains are long, it takes more time. 

--

Jiqiang

[Ben Goodrich]

On Monday, July 23, 2012 10:18:13 PM UTC-4, Bob Carpenter wrote:

> 2. In stan/gm/ast_def.cpp and probably some other place,
> we have code that writes to standard error output.  R CMD check would report a warning (but not pointing out the exact
> place) for this.

I find grep -R works really well for normal code.
If there are lots of macros it's pretty useless.

Use git grep, as in

goodrich@CYBERPOWERPC:/opt/stan$ git grep "cerr" src/
 

> In addition, I am thinking of including boost inside RStan now as first I do not think it is easy for users of Windows
> and Mac (including Andrew)
> to install something called boost into the system's header folder.

Difficulty aside, I don't think we want to insist on putting
code in someone's system's header folder!  I know, I know
Ben is going to tell me that's how people roll on Linux, but
this kind of global config has led to nothing but compatibility
heartache in my experience.

Actually, I was going to say that's how people roll on Windows. Whatever is the default location for Boost to install to is what I would assume. But the stan() function should probably have a boost_lib = NULL argument that could be a non-default path. 

Ben

[Bob Carpenter]

On 7/23/12 10:37 PM, Jiqiang Guo wrote:

>
>
> On Mon, Jul 23, 2012 at 10:18 PM, Bob Carpenter <ca...@alias-i.com <mailto:ca...@alias-i.com>> wrote:
>
> What's the status of the function/package doc
> and install instructions? We can test them on Andrew.
>
> If it is on CRAN, typically we do not have installation instruction. The package doc are inside the package and
> once the packaged is installed, the user can see inside R.
>
> I am thinking of writing a simple vignette?

I don't know what that means.

The issue's going to be getting the other packages
installed. If they just try to install rstan and
run it, it won't work. So we need to have some way to
let them know that!

> But there are a couple of issues.
> 1. I am looking the the effective sample size calculation now. We need something that works not slow and
> supports one
> chain.
>
>
> I'm sure we can fix this. It's probably be
> something a profiler will pick up right away.
> I'll get back to it after finishing the manual
> revision if Daniel doesn't fix it.
>
>
> Sure we can fix. I profiled a bit and realized we are computing all orders of auto-correlations.
> So definitely when the chains are long, it takes more time.

Is that where the time's going? The FFT calcs
all of the auto-correlations in O(N log N) time. To
compute the first K takes O(K N), so the FFT should
be OK here. Maybe the constants are killing us?

- Bob

[Jiqiang Guo]

On Mon, Jul 23, 2012 at 9:38 PM, Ben Goodrich <goodri...@gmail.com> wrote:

to install something called boost into the system's header folder.  Second at least on Linux, I could monitor all the file IO, 

for example, for make test-all, so that I could get a list of all boost header files that are opened.  We might be able to downsize

boost header files from 100M to around 20M.  I am not sure this is a good idea and if I have not thought about something important. 

I split the original mrp to mrp and mrpdata.  So we cannot even try to see what CRAN would think.  I could accept that CRAN would tell me to split RStan to RStan and another package including the necessary boost header files, which is a bit absurd, but it is a better way for the end user.  Anyway, it would be better to have boost_lib as an argument of stan (Ben's suggestion in another mail) as a fall back plan. 

If I remember correctly, CRAN made Malecki split mrpdata from mrp over 6 MB. So, I would guess they would have a problem with boost no matter how small we make it. I imagine most R users could manage if rstan would offer to open a web browser to http://www.boost.org/users/download/ .
 

 

Last, I got rid of the symbol links used before as what works on linux is not working on windows.  So typical `R CMD build (and INSTALL)`

would not work now.  But I have a simple makefile in folder rstan, which could be used to build and install RStan before we could get it on CRAN. 

If the makefile route works, that is fine. But the symlink thing should work as well. As long as we do R CMD build rstan on Linux and upload that to CRAN, people who download the source from CRAN will get hard versions of whatever we symlink. It is only a problem for Windows people who download (R)stan from Google code. and try to build from source.

Well.  It also helps me when I test if on windows.  

Is there any progress on LinkingTo RcppEigen rather than including the Eigen headers in RStan?

I am flipping the some comments on and off to test RcppEigen now.  

[Bob Carpenter]

On 7/23/12 10:43 PM, Ben Goodrich wrote:
> On Monday, July 23, 2012 10:18:13 PM UTC-4, Bob Carpenter wrote:

> Use git grep, as in
>
> goodrich@CYBERPOWERPC:/opt/stan$ git grep "cerr" src/

Cool. Git's the emacs of version controllers!

>
> Actually, I was going to say that's how people roll on Windows. Whatever is the default location for Boost to install to
> is what I would assume. But the stan() function should probably have a boost_lib = NULL argument that could be a
> non-default path.

1. Boost's just a tarball, so there's no install per se
(unless you build their non-header-only libs, but you do
that once you download it).

2. There aren't standard header library directories
on Windows out of the box. Maybe MSVC has some
conventions or maybe R does.

A boost_lib arg is enough to make me happy.

- Bob

[Ben Goodrich]

On Monday, July 23, 2012 10:49:21 PM UTC-4, Bob Carpenter wrote:

On 7/23/12 10:37 PM, Jiqiang Guo wrote:
> I am thinking of writing a simple vignette?

I don't know what that means.

A vignette is less technical documentation that can be written as a free-form PDF. There should probably be a short one just because some people are in the habit of looking for one because the technical documentation tends to be pretty useless for useRs.

Ben

[Bob Carpenter]

>> 2. In stan/gm/ast_def.cpp and probably some other place,
>> we have code that writes to standard error output. R CMD check would report a warning (but not pointing out the exact
>> place) for this.

I just cleared those out. Right now, the
only place writing to std::cout is the command.

Will R be OK with that?

The parser fix won't be noticeable to anyone -- it
just involved passing references from higher up.

The bigger change is in the actual sampler. There's
now a method called

set_error_stream(std::ostream& o);

to set the stream to which error messages (like
domain errors in evaluating probability functions) are
written. The default's to not print them anywhere.

I then pass this stream down to the leapfrog algorithms
that need to report somewhere when they get an
exception evaluating the probability and gradient
(usually domain errors due to zeroes, infinities, NaN, etc.)

- Bob

[Ben Goodrich]

On Tuesday, July 24, 2012 1:09:07 AM UTC-4, Bob Carpenter wrote:

>> 2. In stan/gm/ast_def.cpp and probably some other place,
>> we have code that writes to standard error output.  R CMD check would report a warning (but not pointing out the exact
>> place) for this.

I just cleared those out.  Right now, the
only place writing to std::cout is the command.

Will R be OK with that?

Most likely it will still generate a warning because for anyone who interfaces R via some GUI (i.e. 99%), std::cout is not visible. So, if the parser fails, the useR typically wouldn't know why. The system() function has an option to capture output, which could then be printed in an R session (I think).

Is it possible to pass an optional filename to stanc such that if specified, output is written to that file rather that std::cout ?

Ben

[Jiqiang Guo]

R CMD check gives no warning now as in RStan's version of stanc and the sampler, std::cout

is essentially replaced by R's Rprinf. 

--

Jiqiang

[Bob Carpenter]

On 7/24/12 7:58 AM, Ben Goodrich wrote:
>
> Is it possible to pass an optional filename to stanc such that if
> specified, output is written to that file rather that std::cout ?
>

Yes. Use option "--o=<file>".

You can also do this by setting the name of the model,
which also changes the name inside the file. I couldn't
figure out how we'd want to do the naming, so I left
it flexible from stanc. It's easy to add other features,
too. Right now, it's pretty minimal:

~/stan> bin/stanc --help

stanc version 1.0.0

USAGE: stanc [options] <model_file>

OPTIONS:

--help Display this information

--version Display stanc version number

--name=<string> Model name
(default = "anon_model")

--o=<file> Output file for generated C++ code
(default = "$name.cpp")

- Bob

[Jiqiang Guo]

I have pushed the change in RStan to use Rcppeigen. 

--

Jiqiang