requirements for restarting sampling

[Marco Inacio]

Hi, I'm planning on (trying to) extend Stan C++ API to allow resume sampling.

These topics were pretty helpful:
https://groups.google.com/d/topic/stan-users/20-MVa4AhtQ/discussion
https://groups.google.com/d/topic/stan-users/ZBoWFFvyVJw/discussion
(and also some info in the old txt to-do list)

But I'm still not sure which variables are required to resume iteration with the same adaptation state.

For unit_e, it seems to me that only step size is required (which would mean that it's already possible to resume adaptation).

For diag_e and dense_e, of course we need the matrices of the diagonal/full mass matrix, but other than that maybe some elements (which ones?) of the varying step size adaptation?

The model parameters could be the parameters of the last iteration, right? Are the momentum parameters also needed?

[Michael Betancourt]

Sampler parameters and the state of the random number generator both need

to be saved and then input back into Stan which is currently not possible.  We

have plans for doing this as soon as the current refactoring is complete — it’s

relatively high on the priority list.

--
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.

[Marco Inacio]

Yes, but assuming reproducibility is not important (I know it is), is there anything other than position/momentum variables, step size and the mass matrix elements (for diag_e and mass_e) that needs to be saved?

[Bob Carpenter]

Marco:

I'd break it down into two steps, which can be done
in either order.

Step 1: Modify the commands to allow mass matrices
for input.

Step 2: Modify the commands to save the mass matrices
and current state of the PRNG.

I don't see an easy way to save the state with the PRNG
we're using now:

http://www.boost.org/doc/libs/1_55_0/doc/html/boost/random/ecuyer1988.html

So this may also involve:

Step 3: Replacing the PRNG with Ben's suggested alternative:

http://numbercrunch.de/trng/

It has better PRNG properties. But I don't know if it lets you save
a seed easily.

Alternative: Using the RNG to generate a seed to save. Use that
seed to restart. That makes it reproducible, but doesn't make the
result the same as what you'd get by running one long chain.

- Bob



If we really want to set things up so that if you
restart you get the same samples as if you'd run longer,
we do need to save the RNG seed.

I think it may be problematic with the current Boost
PRNGs, because I don't think there's a way to save a seed
or other state from them to restart. But we've been
talking about updating the PRNG for a while now --- I don't
know if the one Ben suggested would be easier:

But that's not technically necessary for reproducibility,
if you can save a seed, then restart with it.

[Marco Inacio]

Thanks, that makes it more clear.

Today I tried to restart sampling with unit metric reusing the stepsize
and the values of the last iterations as initial values and it didn't
seem to work, I wonder what is missing and I'm faling to see here.

>> have plans for doing this as soon as the current refactoring is complete -- it's

[Michael Betancourt]

I encourage you to hold off on this as any implementation will likely
conflict with much of the ongoing refactor, as I noted before.

[Daniel Lee]

Marco,

Go ahead with updating implementation. As long as it's in Stan proper, the fixes should be easy to propagate. I'm refactoring now, but I'm trying to cut down on duplicated code by using what's in Stan.

Daniel

[Marco Inacio]

I think you are right and that's what I do.

Still (and sorry to keep bothering on this) if you or someone could
answer my last question, it would be good to help me better understand
HMC, NUTS and Stan.

[Bob Carpenter]

Could you remind me what the last question was? The
note below isn't enough to go on.

How did it not work? Did you set num_warmup=0 when restarting?

- Bob

[Marco Inacio]

When I tried to continue sampling using warmup=0, it just made the
iterations go very quick.

And that's why I noticed there was something wrong since it was a very
slow model when I first run it (both for adaptation and sampling).

Then I changed warmup to 1 or 2 and it was still quick. It started being
slow again (as expected) with warmup=10 or more, but how reliable would
be this result then?

fit2 <- sampling(modelObj, data = zi_model_dat,
warmup = 0,
iter = 1000, chains = 1, sample_file = tempf,
init = as.matrix(fit)[1000,], refresh=1, verbose=TRUE,
control = list(
metric="unit_e",
max_treedepth=10, #this is needed in this model to get reasonable mixing
stepsize=0.0151942
))

[Bob Carpenter]

I'm not sure what that sampling() function does. How's init
working?

Have you tried "adapt engaged=false" in Stan? That will
turn off adaptation altogether.

What happens to the samples with warmup=0? Are they starting from
the right init? Reporting the right step size? Mixing?

- Bob

[Ben Goodrich]

On Wednesday, April 9, 2014 8:19:27 AM UTC-4, Bob Carpenter wrote:

I'm not sure what that sampling() function does.  How's init
working?

The stan() function is a wrapper around sampling() but sampling() can also be called directly.

Ben

[Marco Inacio]

The inits for the variables seems to be right

With:

warmup=0 AND adapt_engaged=TRUE:
stepsize is not honored. Sampler uses stepsize=1 and three_depth=1 for
all iterations.


warmup=10 AND adapt_engaged=TRUE:
stepsize is not honored. Sampler adapts stepsize=1 and three_depth for
iterations. But the initial stepsize is not the one I set.


warmup=0 AND adapt_engaged=FALSE:
stepsize is honored, but sampler undesirably uses three_depth=1 for all
iterations.


warmup=10 AND adapt_engaged=FALSE:
same as the above.