ADVI: lp__ is 0 and there is no extra sample for the mode

[John Reid]

Hi, AFAICT if I ask for the rstan::vb() method (version 2.9.0-3) for 1000 samples I get 1000 samples. I'm sure I used to get an extra one representing the mode of the posterior. Has the behaviour changed? Also the lp__ parameter is 0 for all the samples, should that be the case? Thanks, John.

[Dustin Tran]

Hi John, The output of ADVI is the posterior mean estimates along with drawn samples. I don’t think RStan outputs the posterior mean; you have to get it in a more roundabout way through taking the empirical mean of the samples. (Maybe this should change)

The lp__ parameter is intentionally set to 0 for all samples. There were arguments for and against this. The argument for is that unlike MCMC, ADVI has to take additional computation time to calculate it (it draws samples and does all this post processing after its optimization); this can be expensive especially in the settings where ADVI is supposed to be much faster than MCMC but would be bottlenecked by the many log_prob calls after the fact. The argument against is to be compatible with the output of MCMC.

Hope that helps.

Dustin

On Mar 3, 2016, at 10:26 AM, John Reid <johnba...@gmail.com> wrote:

Hi, AFAICT if I ask for the rstan::vb() method (version 2.9.0-3) for 1000 samples I get 1000 samples. I'm sure I used to get an extra one representing the mode of the posterior. Has the behaviour changed? Also the lp__ parameter is 0 for all the samples, should that be the case? Thanks, John.

--
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.
To post to this group, send email to stan-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Reid]

That certainly does help. Presumably I was seeing that extra posterior mean sample using CmdStan.
Thanks,
John.

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

[Ben Goodrich]

On Friday, March 4, 2016 at 4:11:07 AM UTC-5, John Reid wrote:

That certainly does help. Presumably I was seeing that extra posterior mean sample using CmdStan.

The ADVI optimum in the transformed space can be recovered, somewhat confusingly, by the get_inits() function in RStan.

Ben

[John Reid]

Is this documented anywhere?  get_inits() returns a list that I thought was parameter values in the constrained space but occasionally some of them are outside their constrained values.

[John Reid]

I'm guessing having parameters outside the constrained values is a bug. I didn't find any documentation in R that sheds any light on what should be happening.

[Krzysztof Sakrejda]

Could you file an issue with a reproducible example? The right repo should be "github.com/stan-dev/rstan".  Recently it seems like we've been really swamped with some redesign work and issues like this fall by the wayside if a github issue isn't filed with a reproducible example.

[Bob Carpenter]

You're getting the unconstrained parameters, so no values are outside
the constraints. Then the inverse transforms are guaranteed to produce
well-constrained results (up to numerical issues like underflow/overflow).

- Bob

[John Reid]

I have a reproducible example and will file it. However Bob says get_inits should be returning the unconstrained parameters but I find that hard to believe. The return value is a named list which seems to be how constrained parameters are held rather than a vector which seems normally to be used for unconstrained parameters. Also the offending parameters are below 0 extremely rarely which seems surprising.

--

[Krzysztof Sakrejda]

My guess would be that Bob is right but users who are not developers seem to have a magical ability to come up with corner cases and without a reproducible example it's all speculation.

[Ben Goodrich]

On Friday, March 11, 2016 at 3:40:17 AM UTC-5, John Reid wrote:

I have a reproducible example and will file it. However Bob says get_inits should be returning the unconstrained parameters but I find that hard to believe. The return value is a named list which seems to be how constrained parameters are held rather than a vector which seems normally to be used for unconstrained parameters. Also the offending parameters are below 0 extremely rarely which seems surprising.

The named list thing is understandable because the function takes the first numeric row of the csv file and puts it into a list. But I can't imagine how a positively constrained parameter would be occasionally negative.

Ben

 

[John Reid]

Can I just get this straight? The CSV file contains samples from the unconstrained space? rstan should be returning these samples by something is going wrong? I notice you made a fix as a result of my issue https://github.com/stan-dev/rstan/issues/278 Does this fix the problem and will the fix be in the next release of rstan?

Thanks, John.

 

[Ben Goodrich]

On Monday, March 14, 2016 at 1:15:37 PM UTC-4, John Reid wrote:

Can I just get this straight? The CSV file contains samples from the unconstrained space? rstan should be returning these samples by something is going wrong? I notice you made a fix as a result of my issue https://github.com/stan-dev/rstan/issues/278 Does this fix the problem and will the fix be in the next release of rstan?

The CSV file --- which is in tempdir() --- only contains parameter values in the constrained space. However, the lp__ thing in the first column was throwing what is returned by get_inits() off-by-one. This is fixed on GitHub, so you could install that or it will be in the next release of rstan.

Ben