restricted order of lower=, upper=

[Bob Carpenter]

In order to get Stan to compile on Windows,
I reduced the grammar complexity so that only
the following are legal:

int<lower=L,upper=U>
int<lower=L>
int<upper=U>

Two cases from the fully general definition are
missing:

int<upper=U,lower=L>
int<>

Ditto for "real".

Although it doesn't seem like much, it cut down
on the complexity of the grammar rules.

The question is whether we want to allow the
backwards order. I see some benefit in eliminating
the two cases that are missing.

Also, should I do the same thing for truncation,
as in converting

y ~ normal(0,1) T[0,];

to

y ~ normal(0,1) T<lower=1>;

I prefer the interval notation, because the angle
brackets evoke type constraints for me due to
C++ and Java.

- Bob

[Marcus Brubaker]

I'm not worried about the missing cases myself.

The truncated distribution notation is something of a special case and distinct from variable declarations.  I'm not sure I'd change it unless someone feels strongly about it.

Cheers,
Marcus

- Bob

--

[Ben Goodrich]

If the lower bound is equal to the upper bound, does that imply to the C++ code that the variable should be treated as a constant? What about if the bounds are parameterized but equal?

Ben

[Bob Carpenter]

The transform uses the scaled inverse logit.

x = low + (high - low) * inv_logit(y)

If low == high, then x = low.

The gradient is zero in this case, but the
random momentum will keep y flying around, which
should be OK.

I need to make sure to add some error checking.
There isn't any right now! And then I need to
doc the behavior clearly.

- Bob

> --
>
>

[Matt Hoffman]

This might be ok sometimes, but it probably won't be in general.
Consider the scenario where the initial momentum for y is large
compared to the momenta for the other variables. y is going to get a
good running start in some random direction, and the other variables'
trajectories are going to take a little while to turn around. But by
the time they do, the overall trajectory will be dominated by the y
dimension, so we'll never satisfy the u-turn criterion, so each
iteration runs until we reach max_treedepth.

Basically, improper posteriors are always trouble.

Matt

> --
>
>

[Bob Carpenter]

I changed lub_constrain in prob/transform so that
it throws a std domain error if !(lower < upper).

I also changed the lub_constrain w/o Jacobians so
that it is bounded away from 0 and 1 like the one
with Jacobians. (See the previous message for more
on the ramifications for gradients.)

More on Matt's point about NUTS below.

On 8/18/12 1:24 PM, Matt Hoffman wrote:
> This might be ok sometimes, but it probably won't be in general.
> Consider the scenario where the initial momentum for y is large
> compared to the momenta for the other variables. y is going to get a
> good running start in some random direction, and the other variables'
> trajectories are going to take a little while to turn around. But by
> the time they do, the overall trajectory will be dominated by the y
> dimension, so we'll never satisfy the u-turn criterion, so each
> iteration runs until we reach max_treedepth.
>
> Basically, improper posteriors are always trouble.

Very good point. I hadn't thought about the
implications of the posterior on the transformed
params for the U-turn condition.

I don't know about "always". This wouldn't be a problem
for plain-old HMC!

- Bob