Rstan: naming, system, etc.
Bob Carpenter
I'm with Andrew that we should call the package:
Stan
Though I like caps.
That confuses the code organization a bit now, as
we have a directory:
stan/rstan/rstan
with all of the R stuff in it. How about changing
the name of that to:
stan/R/stan
?
2. I'm looking at the stan.R code that Ben inserted.
It uses a system() call. Is this going to work cross
platform? That's where I was imagining we'd have a
compile command implemented through Rcpp so that the
compiler ran in the same process as R itself.
If we do a system call, we need to worry about supplying
an executable or having users compile the code.
Given our problems with Windows compilers, this may turn
out to be easier than compiling through R(cpp).
I don't understand the design decisions well enough here.
3. Is inline related to Rcpp in any way other than having
the same author? I did find this blog of John Cook's:
http://www.johndcook.com/blog/2011/06/30/calling-cpp-from-r/
- Bob
Ben Goodrich
> 1. Naming
>
> I'm with Andrew that we should call the package:
>
> Stan
>
> Though I like caps.
>
> That confuses the code organization a bit now, as
> we have a directory:
>
> stan/rstan/rstan
>
> with all of the R stuff in it. How about changing
> the name of that to:
>
> stan/R/stan
>
> ?
R/stan/R/ .
But I am not sure we should change the name of the R package to stan.
The dominant naming convention for R packages that interface with
external software is to have R or R2 or something in the name
(R2WinBUGS, RcppEigen, etc.). If you ever intend to have them packaged
for Linux distributions, having two source packages with the same name
will cause some headaches. Finally, since stan the library is BSD and
stan the R package is GPL, I'd say that having distinct names would be
less legally confusing.
> 2. I'm looking at the stan.R code that Ben inserted.
> It uses a system() call. Is this going to work cross
> platform? That's where I was imagining we'd have a
> compile command implemented through Rcpp so that the
> compiler ran in the same process as R itself.
was only introduced into R a couple of years ago.
> If we do a system call, we need to worry about supplying
> an executable or having users compile the code.
the user installs the R package (whether they build it from source or
install the binary R package). For executables like particular models,
then the user would have to compile them, in which case on Windows
they need the Rtools toolchain (not VisualStudio).
> 3. Is inline related to Rcpp in any way other than having
> the same author? I did find this blog of John Cook's:
Sklyar. The inline package is a suggestency of the Rcpp package
because some R functions in Rcpp utilize inline.
Ben
Andrew Gelman
Bob Carpenter
> On Feb 28, 3:49 pm, Bob Carpenter<c...@alias-i.com> wrote:
>> 1. Naming
>>
>> I'm with Andrew that we should call the package:
>>
>> Stan
>>
>> Though I like caps.
> That is okay, although has the confusion that a directory will be stan/
> R/stan/R/ .
I was confused already by stan/rstan/rstan, but I don't know
the R conventions for laying out code.
> But I am not sure we should change the name of the R package to stan.
> The dominant naming convention for R packages that interface with
> external software is to have R or R2 or something in the name
> (R2WinBUGS, RcppEigen, etc.).
You'll have to take that one up with andrew. I only know
R2WinBugs and R2jags and Rcpp, but Andrew thought having the
R was tacky.
> If you ever intend to have them packaged
> for Linux distributions, having two source packages with the same name
> will cause some headaches. Finally, since stan the library is BSD and
> stan the R package is GPL, I'd say that having distinct names would be
> less legally confusing.
(R)?2(S|s)tan the R package will be BSD-ed, too.
Only the *combination* of R2stan and R become
GPL-ed. That'll let us host on Google Code (which
doesn't or at least didn't allow GPL code hosting),
and also let people distribute all of (R)stan without
worrying about the GPL (unless they link to R and
redistribute).
>> 2. I'm looking at the stan.R code that Ben inserted.
>> It uses a system() call. Is this going to work cross
>> platform? That's where I was imagining we'd have a
>> compile command implemented through Rcpp so that the
>> compiler ran in the same process as R itself.
>
> Yes. Nowdays there is system2() which is more portable in a sense but
> was only introduced into R a couple of years ago.
>
>> If we do a system call, we need to worry about supplying
>> an executable or having users compile the code.
>
> Executable what exactly? Executables like demo/gm should exist once
> the user installs the R package (whether they build it from source or
> install the binary R package). For executables like particular models,
> then the user would have to compile them, in which case on Windows
> they need the Rtools toolchain (not VisualStudio).
I'm clearly very confused about how all the pieces fit
together here and who's in charge of what and when things
get compiled. The doc so far hasn't helped, but I haven't
read the 150+ page R extensions package manual.
- Bob
Ben Goodrich
What I had in my head was that the R package would have an inst/include/ directory that basically contained stan/src/. When the R package gets installed (from source), the installation would essentially involve a "make demo/gm". That is essentially what the RcppEigen package does. The binary version of the R package (built from source by / on CRAN's servers) would thus have the demo/gm executable.
Once the R package is installed and loaded, the main stan() function would use the system() or system2() function to pass a .stan text file to demo/gm to yield the C++ file, which would then get processed by Rcpp's magic. Then, the main stan() function would use the .Call() function in R to pass the data to the just-compiled model and execute.
But there are probably other ways to do it as well.
Ben
Andrew Gelman
Andrew Gelman
A