some stan language questions

[Andrew Gelman]

Hi, Bob. I'm writing some stuff in BDA3 on Stan and in preparation am reading the manual. I have some questions:

1. Why do we need bounds in a data statement (for example, int(0,) N;)? Data are just data, so what is the point of the bounds? Is it for later, when we want to do "forward simulation" for posterior predictive checking and debugging?

2. In math notation, (a,b) is an open interval, i.e. it can't equal a or b. In the manual, you define bounds as closed (e.g., real(0,1) takes on continuous values between 0 and 1 inclusive). I have 2 questions. (a) could we use [] notation for inclusive because that would be consistent with math, or is that just too messy for parsing? (b) I think that for continuous models with bounds, we _don't_ want the bounds to be included. Thus the notation only arises for discrete random variables. (And I agree that it would be awkward to use "int(-1,2)" to indicate a 0/1 binary variable.)

I'm sure I'll have more questions to come…

[Bob Carpenter]

On 7/31/12 4:33 PM, Andrew Gelman wrote:
> Hi, Bob. I'm writing some stuff in BDA3 on Stan and in preparation am reading the manual. I have some questions:
>
> 1. Why do we need bounds in a data statement (for example, int(0,) N;)? Data are just data, so what is the point of the bounds? Is it for later, when we want to do "forward simulation" for posterior predictive checking and debugging?

They're optional. There are two points. One is to declare
the intent of the model so that it's easier to read and
understand. Two is to catch errors as early as possible.

> 2. In math notation, (a,b) is an open interval, i.e. it can't equal a or b.
> In the manual, you define bounds as closed (e.g., real(0,1) takes on continuous
> values between 0 and 1 inclusive). I have 2 questions. (a) could we
> use [] notation for inclusive because that would be consistent with math,
> or is that just too messy for parsing?

Changing Stan to use () instead of [] is no problem.
It'll require changing every single model and the
doc. The models we can probably change pretty
automatically and the doc semi-automatically.

The reason it was originally (a,b) was because it's
theoretically open. For example, in math, exp
maps (-inf,inf) to (0,inf), both exclusive.
In IEEE arithmetic, you get underflow so that
any number less than -800 or so maps to 0 and
any number greater than 800 goes to infinity (it's
actually a value in IEEE arithmetic).

> (b) I think that for continuous models with
> bounds, we _don't_ want the bounds to be included.

That's a bit trickier. See above. We'd have to
somehow bound everything away from 0 and +inf.

> Thus the notation only
> arises for discrete random variables. (And I agree that it would be awkward
> to use "int(-1,2)" to indicate a 0/1 binary variable.)

Yeah, we don't want int(-1,2), int[0,1] would be better.

> I'm sure I'll have more questions to come�

Bring 'em on!

- Bob

[Andrew Gelman]

On Aug 1, 2012, at 5:30 AM, Bob Carpenter wrote:

Changing Stan to use () instead of [] is no problem.
It'll require changing every single model and the
doc.  The models we can probably change pretty
automatically and the doc semi-automatically.

No, I think you got me backwards.  I'm not suggestiong to use () instead of [].  It's the opposite:  I was suggesting to use [] instead of () for intervals, because I think in practice we can make these all closed intervals and it will work.  I would still keep [] for subscripting.

In that case, the notation [] will have two different meanings.  My quesiton is then: can the parser handle this?  If so, I think I'd like it.  In the manual, we're already defining intervals as closed, so it would be convenient to use the standard math notation for these.

[Bob Carpenter]

On 8/1/12 3:35 PM, Andrew Gelman wrote:
>
> On Aug 1, 2012, at 5:30 AM, Bob Carpenter wrote:
>>
>> Changing Stan to use () instead of [] is no problem.
>> It'll require changing every single model and the
>> doc. The models we can probably change pretty
>> automatically and the doc semi-automatically.
>
> No, I think you got me backwards.

Sorry -- that was a typo. I was distracted by the beaches
of Lake Michigan :-)

> I'm not suggestiong to use () instead of []. It's the opposite: I was suggesting to
> use [] instead of () for intervals, because I think in practice we can make these all closed intervals and it will work.
> I would still keep [] for subscripting.

Of course.

> In that case, the notation [] will have two different meanings. My quesiton is then: can the parser handle this? If
> so, I think I'd like it. In the manual, we're already defining intervals as closed, so it would be convenient to use
> the standard math notation for these.

Yes, the parser can handle it. We should be able to
handle just about anything that's not ambiguous.

I'll change it when I get back. I don't know that
anyone else wants to mess with the parser -- if someone
does, it should just be a few symbols in the
variable declaration grammar. And then a fancy global
search and replace on our existing models and in the
manual.

- Bob

[Andrew Gelman]

Thx. And enjoy Lake M.