silent stan?

[Andrew Gelman]

Is there a way to run stan() in R and not give output to the terminal? I'm running it in a loop and I don't want to fill up my screen with output. I looked around on web and there seems to a be a general approach using sink() but this seems a bit ugly to me, can it be done more directly??
thx
a

[Sergio Polini]

Il 15/12/2013 15:42, Andrew Gelman ha scritto:
> Is there a way to run stan() in R and not give output to the terminal? I'm running it in a loop and I don't want to fill up my screen with output. I looked around on web and there seems to a be a general approach using sink() but this seems a bit ugly to me, can it be done more directly??

May I? Running stan() in a loop looks like compiling a model many times.

foo.sm <- stan_model("foo.stan", ...)
for (i in 1:N) {
...
foo.sf <- sampling(foo.sm, data=...)
...
}

would be better than:

for (i in 1:N) {
...
stan("foo.stan", data=...)
...
}

As to the output you wish to suppress,
a) stan(..., refresh=-1) and sampling(...,refresh=-1) don't indicate the
progress during sampling;
b) the suppressWarnings() R function could suppress warning messages,
but I've not tried - and I'd like to look at warnings.

HTH

Sergio

[Andrew Gelman]

Sergio:
Thanks. Actually, I'm running stan(fit=…) in the loop, so it doesn't recompile each time. I tired refresh=-1 but it still gives me a blank line for each chain.
A

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

[Sergio Polini]

Il 15/12/2013 16:12, Andrew Gelman ha scritto:
> Sergio:

> Thanks. Actually, I'm running stan(fit=�) in the loop, so it doesn't recompile each time.

Ok. stan(fit=...) just calls sampling().

> I tired refresh=-1 but it still gives me a blank line for each chain.

Yes. I'd say that it's a nuisance ("bug" would be ovestated).
I can't fully understand the source code. My best guess: in
stan_2.0.1/src/stan/gm/command.hpp there are several "std::endl". They
usually are used:
a) when printing error messages;
b) otherwise, after controlling for refresh;
but there is an "Initial output":

// Initial output
parser.print(&std::cout);
std::cout << std::endl;

Do those newlines come from this code? May be ;-)

Sergio

[Bob Carpenter]

I'm guessing that Andrew's running under RStan, not
the command line. RStan rewrites the command.hpp to
use R I/O and data structures rather than what the command
line uses. For example, it passes in the R input/output
streams rather than using std::cout and std::cerr.

I opened an issue for CmdStan, which outlines three ways
it could be done in the code:

https://github.com/stan-dev/stan/issues/453

The same sort of thing will need to be done for RStan (and
presumably PyStan).

- Bob

[Andrew Gelman]

Now I feel bad . . . I hate to waste everyone's time on this one! I did a hack using sink() in R that I found on the web, maybe that's fine, I dunno.

On Dec 15, 2013, at 5:46 PM, Bob Carpenter <ca...@alias-i.com> wrote:

> I'm guessing that Andrew's running under RStan, not
> the command line. RStan rewrites the command.hpp to
> use R I/O and data structures rather than what the command
> line uses. For example, it passes in the R input/output
> streams rather than using std::cout and std::cerr.
>
> I opened an issue for CmdStan, which outlines three ways
> it could be done in the code:
>
> https://github.com/stan-dev/stan/issues/453
>
> The same sort of thing will need to be done for RStan (and
> presumably PyStan).
>
> - Bob
>
>
>
>
> On 12/15/13, 11:12 AM, Sergio Polini wrote:
>> Il 15/12/2013 16:12, Andrew Gelman ha scritto:
>>> Sergio:

>>> Thanks. Actually, I'm running stan(fit=…) in the loop, so it doesn't recompile each time.

>>
>> Ok. stan(fit=...) just calls sampling().
>>
>>> I tired refresh=-1 but it still gives me a blank line for each chain.
>>
>> Yes. I'd say that it's a nuisance ("bug" would be ovestated).
>> I can't fully understand the source code. My best guess: in stan_2.0.1/src/stan/gm/command.hpp there are several
>> "std::endl". They usually are used:
>> a) when printing error messages;
>> b) otherwise, after controlling for refresh;
>> but there is an "Initial output":
>>
>> // Initial output
>> parser.print(&std::cout);
>> std::cout << std::endl;
>>
>> Do those newlines come from this code? May be ;-)
>>
>> Sergio
>>
>

[Bob Carpenter]

As you've observed on the R mailing lists, the easy questions
get more attention.

Like all of our minor bug fixes, it requires a few minutes
to create the issue, a few minutes to code, probably an hour
to write tests for (which should've been there in the first
place), then a few more minutes to get it code reviewed, then
as long as it takes to get it through Jenkins integration testing
without failure. But then it takes longer if we can't get
it reviewed, if someone has comments on the way it's written
and it needs to be rewritten, if another fix comes in in parallel
and they need to be merged, etc..

Overall, I'd be surprised if we could fix an issue like this
using our current process in less than several person hours
and less than forty CPU, hours (about how long our tests
take to run --- we do four cores in parallel, so that's only
ten hours wall time).

The reason we're being so Draconian on all the testing is
that we don't want "little fixes" like this one to break
anything else that matters.

I think the real danger is that we spend all of our time
effectively straightening our desks and marching in tune with
our process on issues like this one and less time on the
issues that really matter.

- Bob

On 12/15/13, 11:48 AM, Andrew Gelman wrote:
> Now I feel bad . . . I hate to waste everyone's time on this one! I did a hack using sink() in R that I found on the web, maybe that's fine, I dunno.
>
> On Dec 15, 2013, at 5:46 PM, Bob Carpenter <ca...@alias-i.com> wrote:
>
>> I'm guessing that Andrew's running under RStan, not
>> the command line. RStan rewrites the command.hpp to
>> use R I/O and data structures rather than what the command
>> line uses. For example, it passes in the R input/output
>> streams rather than using std::cout and std::cerr.
>>
>> I opened an issue for CmdStan, which outlines three ways
>> it could be done in the code:
>>
>> https://github.com/stan-dev/stan/issues/453
>>
>> The same sort of thing will need to be done for RStan (and
>> presumably PyStan).
>>
>> - Bob
>>
>>
>>
>>
>> On 12/15/13, 11:12 AM, Sergio Polini wrote:
>>> Il 15/12/2013 16:12, Andrew Gelman ha scritto:
>>>> Sergio:

>>>> Thanks. Actually, I'm running stan(fit=�) in the loop, so it doesn't recompile each time.

[Andrew Gelman]

OK, next time I have an issue like this, I will write it on a sheet of paper and bring it up later!

>>>>> Thanks. Actually, I'm running stan(fit=…) in the loop, so it doesn't recompile each time.

[Bob Carpenter]

On 12/15/13, 11:57 AM, Andrew Gelman wrote:
> OK, next time I have an issue like this, I will write it on a sheet of paper and bring it up later!

Please bring them up as soon as you notice them in whatever
medium you'd like. The reaction doesn't depend on the medium
(other than that we might spare our lists the traffic).

These issues might have already been solved and just not documented
well enough, or they may indicate some kind of confusion
in design so that they're not really bugs per se. Or like this
one, they might be tiny bugs. I'd much rather see them and record
them in the issue tracker than just ignore them. We might just
continue to effectively ignore whatever the issue is by prioritizing
other things.

- Bob

>>>>>> Thanks. Actually, I'm running stan(fit=�) in the loop, so it doesn't recompile each time.

[Leon Peshkin]

   Hello !
I would like to be able to run the Rstan code in a "production mode" suppressing any output unless things just break completely.
Perhaps someone could post an example of this "sink()" hack with RStan ?

  I just tried defining sink() into a file and still get the following errors/warnings below are three examples,
by the way there is a type "occured" in the message.

    thanks !
 -Leon

Exception thrown at line 23: beta_binomial_log: Second prior sample size parameter is inf, but must      1
When a numerical problem occurs, the Hamiltonian proposal gets rejected.
See http://mc-stan.org/misc/warnings.html#exception-hamiltonian-proposal-rejected
If the number in the 'count' column is small, do not ask about this message on stan-users.


The following numerical problems occured the indicated number of times on chain 1
                                                                                                     count
Exception thrown at line 23: beta_binomial_log: First prior sample size parameter is 0, but must be      1
When a numerical problem occurs, the Hamiltonian proposal gets rejected.
See http://mc-stan.org/misc/warnings.html#exception-hamiltonian-proposal-rejected
If the number in the 'count' column is small, do not ask about this message on stan-users.


The following numerical problems occured the indicated number of times on chain 1
                                                                                                     count
Exception thrown at line 23: Error in function boost::math::lgamma<double>(double): numeric overflow     1
When a numerical problem occurs, the Hamiltonian proposal gets rejected.
See http://mc-stan.org/misc/warnings.html#exception-hamiltonian-proposal-rejected
If the number in the 'count' column is small, do not ask about this message on stan-users.