Re: [stan-users] include feature from rstan to come to cmdstan?

[Bob Carpenter]

[moved to stan-dev]

> On Dec 14, 2015, at 4:24 PM, Ben Goodrich <goodri...@gmail.com> wrote:
>
> On Monday, December 14, 2015 at 2:47:35 PM UTC-5, Bob Carpenter wrote:
> My goal is to put everything in Stan itself so that our
> interfaces are consistent and can be described in a single
> modeling manual.
>
> For mathematical functions, estimation algorithms, and other things that actually involve modeling, that usually makes sense from a cost-benefit perspective. But this is basically copying and pasting of text, which is a domain that is already well-handled by any scripting language. I wrote it for rstan
>
> https://github.com/stan-dev/rstan/blob/develop/rstan/rstan/R/stanc.R#L71
>
> in a few minutes because it saved me many minutes writing the .stan files for rstanarm. It's been suggested for stanc before and the impression I got was that it would be a ton of work to implement.

We were originally discussing plumbing the C++-like preprocessor
through to allow macros, etc. But we scaled back to just wanting
to do includes of the kind Ben included in RStan 2.8.x.

I understand that some things are easy to implement in R and that
nobody's patient enough to implement them in C or wait until someone
else does.

My concern is that with RStan drifting at the language level, there
are programs that will run in RStan that won't run elsewhere.

How are paths handled with the includes? That is, if I say

#include "foo.stan"

where does RStan look for the "foo.stan" file?

- Bob

[Ben Goodrich]

On Monday, December 14, 2015 at 7:00:18 PM UTC-5, Bob Carpenter wrote:

How are paths handled with the includes?   That is, if I say

  #include "foo.stan"

where does RStan look for the "foo.stan" file?

There is an isystem argument to stanc_builder() that defaults to the directory of the parent file that works like the -isystem argument in g++ or clang++.

Ben

[Sebastian Weber]

I agree with Bob that it is not ideal to have the interfaces drift apart.

The rationale from Ben of how this works makes a lot of sense to me - and this would have saved me from a lot of copy-and-paste as I have written a number of Stan functions which I tend to recycle.

When this goes to cmdstan it would be great to automatically save the final stan model-file which actually get's compiled - for the sake of reproducibility.

Sebastian

[Bob Carpenter]

We can cross that bridge when we come to it.

Do you guys require that of the C preprocessor, too? That
is, that it dump out the translation unit it compiles and links?

- Bob

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

[Sebastian Weber]

Hi Bob!

I think I forgot to answer here. Having the result from the C preprocessor as an intermediate for the purpose of documenting what an analysis actually looked like would be good. In the meantime I figured how a user may define a makefile based solution which I posted on stan-users, i.e. define a rule for .tstan files for example which just pipes a modeling file through the preprocessor creating the final .stan file. If my makefile solution is sufficient from your perspective, then documenting this makefile trick somewhere should be enough to make users happy, I guess.

Best,

Sebastian

--
You received this message because you are subscribed to a topic in the Google Groups "stan development mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stan-dev/q_hGJTq6xug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stan-dev+u...@googlegroups.com.