new Stan command output & lp__ increment() function

[Bob Carpenter]

I'm writing out examples for the paper to check that it's
consistent with current behavior and seeing this:

# Step size = 1.8359
# Diagonal elements of inverse mass matrix:
# 0.529535

Shouldn't "Step size" now be "time interval" or something
like that?

And can we be super-specific and say the following?

"Diagonal elements of diagonal inverse mass matrix:"

I also thought the header was going to change names for
things, too:

lp__,accept_stat__,stepsize__,treedepth__,theta

What is accept_stat__? I couldn't find a previous discussion
on the stan-dev list or in the latest manual.

One issue is whether we're going to change lp__, which is
used in the models. I like the idea of adding a function to
increment lp__, so I'll make a pull request for that. I'll try
to make it all-inclusive by hitting all the models and all the
doc (I won't touch the output headers, though). I'd like our future
pull requests to have everything in them at once so that the dev branch
remains consistent between the doc and the code.

Then we can deprecate direct access to lp__ and print the header
however Michael thinks makes most sense.

I'll also be happy to update the manual examples once we settle
on names.

- Bob

[Ben Goodrich]

On Friday, June 7, 2013 3:29:40 PM UTC-4, Bob Carpenter wrote:

One issue is whether we're going to change lp__, which is
used in the models.  I like the idea of adding a function to
increment lp__, so I'll make a pull request for that.

Can you make the lp_increment() function take a second "warning" argument that defaults to 1, so that the .stan file can do something like

if (condition) lp_increment(negative_infinity(), 0);

in which case, the sampler would immediately reject the proposal without spitting out any long messages and without doing any more calculations for that proposal?

Ben

[Michael Betancourt]

> I'm writing out examples for the paper to check that it's
> consistent with current behavior and seeing this:
>
> # Step size = 1.8359
> # Diagonal elements of inverse mass matrix:
> # 0.529535
>
> Shouldn't "Step size" now be "time interval" or something
> like that?

Why would it be called that? We're always discretizing the flow with a numerical integrator by choosing a step size.

> And can we be super-specific and say the following?
>
> "Diagonal elements of diagonal inverse mass matrix:"

Is metric too esoteric? I would love to get rid of the "mass matrix" terminology.

In any case, we could have

"Elements of the diagonal (inverse mass matrix/inverse metric)"
"Elements of the (inverse mass matrix/inverse metric)"

> I also thought the header was going to change names for
> things, too:
>
> lp__,accept_stat__,stepsize__,treedepth__,theta
>
> What is accept_stat__? I couldn't find a previous discussion
> on the stan-dev list or in the latest manual.

accept_stat is the Metropolis acceptance probability. I haven't doc'd anything in the manual -- can we start a separate thread/issue noting which items need to be documented? With all of the changes in place I'm kind of lost as to what should be put into the manual.

> One issue is whether we're going to change lp__, which is
> used in the models. I like the idea of adding a function to
> increment lp__, so I'll make a pull request for that. I'll try
> to make it all-inclusive by hitting all the models and all the
> doc (I won't touch the output headers, though). I'd like our future
> pull requests to have everything in them at once so that the dev branch
> remains consistent between the doc and the code.
>
> Then we can deprecate direct access to lp__ and print the header
> however Michael thinks makes most sense.

Anything descriptive, whether it be "log_prob" or "log_post", of even "log_posterior".

[Daniel Lee]

Ben, are you sure you don't want a reject() function rather than overloading lp_increment()?
 

[Bob Carpenter]

On 6/7/13 3:54 PM, Daniel Lee wrote:

I prefer reject(), or even better, an even more explicit

raise_exception(...);

Given that we have optimization, etc., "rejection" isn't the
only thing we do. Then it would make sense to allow these
in the transformed data and generated quantities blocks, which
wouldn't ordinarly be able to "reject" because they don't have
access to lp__.


Conditionals would also slow down the usual lp_increment() behavior,
and if we do what Marcus was suggesting in accumulating a vector to
sum, we should actually be able to speed it up.

- Bob

[Ben Goodrich]

On Friday, June 7, 2013 3:54:42 PM UTC-4, Daniel Lee wrote:

Ben, are you sure you don't want a reject() function rather than overloading lp_increment()?

That would be fine too.

Ben
 

[Marcus Brubaker]

On Fri, Jun 7, 2013 at 3:53 PM, Michael Betancourt <betan...@gmail.com> wrote:

> And can we be super-specific and say the following?

>
>  "Diagonal elements of diagonal inverse mass matrix:"

Is metric too esoteric?  I would love to get rid of the "mass matrix" terminology.

I think we should keep the mass matrix terminology if possible.  For people who know HMC they'll (generally) know what the mass matrix is, but the metric is likely to be opaque for most people.

Cheers,

Marcus

[Marcus Brubaker]

This is great, thanks Bob!

- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.