update on variational inference

[Alp Kucukelbir]

hey guys,

happy 2015!

i'm currently working on exposing the parameters of
the variational algorithm to the cmdline. this whole
gm/command structure is really powerful.

that aside, i have two goals that might be worth a
chat with you guys (at least via email/here):

1. robustfication/convergence: i forget who wrote
the optimization stuff, but i think for variational
our best bet is the tol_param strategy (norm of
difference of parameters across interations). i'd
love to hear thoughts on this, especially since
the variational objective function *and* its
gradients are both noisy.

part of this will also be initialization. i'm finding
that our algorithm can be sensitive to bad inits
especially if a stan model has a lot of transformations.
thoughts/strategies would be welcome here too.

2. reporting/output. the idea that many of you
suggested was to draw from the final configuration
of the variational gaussians and transform these
back to the unconstrained domain, then report
quantiles like in sampling etc.

if this is going to be useful for EP etc. then it might
be worth coordinating the design (by which i mean
how it should fit in Stan). if folks can help me
with that, i'll try my best to write decent code to
fill in the rest.

cheers,
alp

[Bob Carpenter]

> On Jan 7, 2015, at 6:40 PM, Alp Kucukelbir <akucu...@gmail.com> wrote:
>
> hey guys,
>
> happy 2015!
>
> i'm currently working on exposing the parameters of
> the variational algorithm to the cmdline. this whole
> gm/command structure is really powerful.
>
> that aside, i have two goals that might be worth a
> chat with you guys (at least via email/here):
>
> 1. robustfication/convergence: i forget who wrote
> the optimization stuff,

Marcus wrote the core of the code.

> but i think for variational
> our best bet is the tol_param strategy (norm of
> difference of parameters across interations). i'd
> love to hear thoughts on this, especially since
> the variational objective function *and* its
> gradients are both noisy.

Stochastic variational inference must have this same
problem. What did Matt do?

> part of this will also be initialization. i'm finding
> that our algorithm can be sensitive to bad inits
> especially if a stan model has a lot of transformations.
> thoughts/strategies would be welcome here too.

You can scale down the range of random inits to keep
initial values on the unconstrained scale close to 0.
That is 0 for unconstrained parameters, 1 for positive
constrained (exp inverse transform), 0.5 for parameters
constrained between 0 and 1 (inverse logit), symmetric
simplexes, unit correlation covariance matrices. We've
generally found those to be better behaved.

It also helps if the data are reasonably scaled.

> 2. reporting/output. the idea that many of you
> suggested was to draw from the final configuration
> of the variational gaussians and transform these
> back to the unconstrained domain, then report
> quantiles like in sampling etc.

Aren't the variational Gaussians on the unconstrained scale?

> if this is going to be useful for EP etc. then it might
> be worth coordinating the design (by which i mean
> how it should fit in Stan). if folks can help me
> with that, i'll try my best to write decent code to
> fill in the rest.

We should get on that ASAP because Andrew wants to use the
same technique for MLE uncertainty.

I'd think one natural thing to do would be to stream the
sample out as a CSV file to match what we produce for MCMC.
Then we can use our existing tools. Those read into a chains
object and you could also construct the chains object
directly from the draws. These are all heavy either in terms
of I/O or memory.

Alternatively, if we only need certain summaries, such as
sample variance or covariance on the constrained scale, we
could efficiently accumulate those on the fly.

- Bob

[Andrew Gelman]

Hi, my only comment is that it could make sense to use some version of HMC or Nuts for initialization, to quickly get to the meat of the distribution. In the initialization stage there is no need for detailed balance and in theory this relaxation of the detailed-balance requirement could give us freedom to do all sorts of fast efficient things. But when we discussed this all with Matt, years ago, he would generally argue that in practice these shortcuts don’t help much.

I do think Matt would have some insight into initialization for VB, given that he’s thought a lot about initialization (in various contexts) and VB (in various contexts).
A

> On Jan 7, 2015, at 6:40 PM, Alp Kucukelbir <akucu...@gmail.com> wrote:
>

[Michael Betancourt]

2. reporting/output. the idea that many of you
suggested was to draw from the final configuration
of the variational gaussians and transform these
back to the unconstrained domain, then report
quantiles like in sampling etc.

Aren't the variational Gaussians on the unconstrained scale? 

Alp is referring to when we map back to the constrained scale.

if this is going to be useful for EP etc. then it might
be worth coordinating the design (by which i mean
how it should fit in Stan). if folks can help me 
with that, i'll try my best to write decent code to 
fill in the rest.

We should get on that ASAP because Andrew wants to use the
same technique for MLE uncertainty. 

I'd think one natural thing to do would be to stream the
sample out as a CSV file to match what we produce for MCMC.
Then we can use our existing tools.  Those read into a chains
object and you could also construct the chains object
directly from the draws.  These are all heavy either in terms
of I/O or memory.

Alternatively, if we only need certain summaries, such as
sample variance or covariance on the constrained scale, we 
could efficiently accumulate those on the fly. 

Memory shouldn’t be an issue — in all of these algorithms we’ll

have some fit results that define distributions from which we can

easily sample (Gaussians for VB, EP, and MML at the moment)

and then compute quantiles online.  Code taking in a vector of

means and standard deviations (or variances) and a model 

capable of doing the unconstrained to constrained mapping

and returning the vector of quantiles should be sufficient.

[Alp Kucukelbir]

>>> 2. reporting/output. the idea that many of you
>>> suggested was to draw from the final configuration
>>> of the variational gaussians and transform these
>>> back to the unconstrained domain, then report
>>> quantiles like in sampling etc.
>>
>> Aren't the variational Gaussians on the unconstrained scale?
>
> Alp is referring to when we map back to the constrained scale.

michael and bob are correct. i mis-typed.

>
>>
>>> if this is going to be useful for EP etc. then it might
>>> be worth coordinating the design (by which i mean
>>> how it should fit in Stan). if folks can help me
>>> with that, i'll try my best to write decent code to
>>> fill in the rest.
>>
>> We should get on that ASAP because Andrew wants to use the
>> same technique for MLE uncertainty.
>>
>> I'd think one natural thing to do would be to stream the
>> sample out as a CSV file to match what we produce for MCMC.
>> Then we can use our existing tools. Those read into a chains
>> object and you could also construct the chains object
>> directly from the draws. These are all heavy either in terms
>> of I/O or memory.
>>
>> Alternatively, if we only need certain summaries, such as
>> sample variance or covariance on the constrained scale, we
>> could efficiently accumulate those on the fly.
>
> Memory shouldn’t be an issue — in all of these algorithms we’ll
> have some fit results that define distributions from which we can
> easily sample (Gaussians for VB, EP, and MML at the moment)
> and then compute quantiles online. Code taking in a vector of
> means and standard deviations (or variances) and a model
> capable of doing the unconstrained to constrained mapping
> and returning the vector of quantiles should be sufficient.

with my limited experience, i would also go for this option.
a function that does:

vector of means/stds + model -> quantiles in constrained domain

would (at least) be sufficient for VB.

[Ben Goodrich]

On Thursday, January 8, 2015 6:52:46 AM UTC-5, Alp Kucukelbir wrote:

with my limited experience, i would also go for this option.
a function that does:

vector of means/stds + model -> quantiles in constrained domain

would (at least) be sufficient for VB.

I think you need the means and the covariance matrix (or Cholesky factor thereof) in order to draw Gaussians that you can then map to constrained parameters.

Ben

[Alp Kucukelbir]

> I think you need the means and the covariance matrix (or Cholesky factor thereof) in order to draw Gaussians that you can then map to constrained parameters.

for the full-covariance algorithm, that's true.

for the mean-field algorithm, it's just the diagonals.

would it make sense to implement both versions separately?
(one function that takes in a vector of variances, another
function that takes in a Cholesky matrix?)

cheers,
alp

[Bob Carpenter]

We'll also be developing general code to do a Laplace
approximation at the mode and dump output of either
posterior means, variances, or covariances from there.

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