revised density/mass notation proposal

[Bob Carpenter]

I think I have everything revised to match what we said today:

https://github.com/stan-dev/stan/wiki/Stan-3-Density-Notation-and-Increments

I translated some models at the end. Some of these look pretty
ugly in their original form, too.

- Bob

[Michael Betancourt]

I think these look great, although you’re missing a l in front of some of the pmf’s.

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

[Aki Vehtari]

> Not clear we really are going to keep computing WAIC, etc., given the current focus on cross-validation.

PSIS-LOO requires same generated quantities computation as WAIC

Simple Normal Mixture example is missing normalisation in the mixture part

Hurdle model has y[n] but no loop

Aki

[Bob Carpenter]

Hey everyone, this doc is editable. I'll make the edits,
but feel free to fix them yourselves.

- Bob

[Eric Novik]

My $0.000002:

I was thinking a lot about this proposed change and I must admit that I share Bob's sentiment here in that it scares the poopies out of me. The first reaction after looking at the ported model code was how ugly (wordy?) this 'target' business looked like. Of course, this is the trivial part so changing from this:

...
model {
  target += normal_lpdf(alpha | 0, 10);
  target += normal_lpdf(beta | 0, 2);
  target += cauchy_lpdf(sigma | 0, 2.5);
  target += normal_lpdf(y | alpha * x + beta, sigma);
}

to, say, this:

...
model {
  lp += normal_lpdf(alpha | 0, 10);
  lp += normal_lpdf(beta | 0, 2);
  lp += cauchy_lpdf(sigma | 0, 2.5);
  lp += normal_lpdf(y | alpha * x + beta, sigma);
}

may or may not make it aesthetically better and as Bob pointed out: "On the specific point of lp vs. target, I don't think it matters much.  It's just going to be this not-quite-a-variable thing that kind of acts like a variable and kind of doesn't. Really ugly semantically and pragmatically, that is." 

On the larger issue, I totally get that the proposed notation is closer to the underlying machinery of Stan, but is it worth pissing off a lot of Stan users who invested time in learning the current notation? Again, quoting Bob:

I think the whole thing looks ugly, and said so
at the meeting.  I'm extremely apprehensive about
this change.  I worry it's going to confuse and
alienate our users (not that they weren't confused
before --- that's what the change is for --- to unconfuse
them).  And I know it's going to piss off everyone who's put
effort into code and doc for the existing system.

We are all users of programming languages. A little empathy for our brothers perhaps?

Eric

[Andrew Gelman]

How about this:

model {
 @ normal(alpha | 0, 10);
 @ normal(beta | 0, 2);
 @ cauchy(sigma | 0, 2.5);
 @ normal(y | alpha * x + beta, sigma);
}

Clean!

[Daniel Lee]

With the examples, I just can't help wanting to add:

   return target;

at the end of the block. I see the model block as a function, so I naturally want to return something.

Instead of @, I think << would be more natural. It's used in c++ as the insertion operator. It's close to the scoping assignment in R (<<-).

I'm still in favor of the more explicit _lpdf / _lpmf suffix.

[Andrew Gelman]

I’m with Eric.  To me, the _lpdf thing is close to a deal-breaker.  Almost everything we are using is an lpdf.  I hadn’t thought so much about it, but seeing Eric’s example, I agree that it’s a lot less user friendly, it’s just a pain in the ass.

If we were setting up models using graphical model expressions, and this was intermediate code, I wouldn’t be so bothered.  But I really really don’t want to be asking people to write their Stan code with “target +=“ on each line and “_lpdf” for each probability assignment.  This truly does feel like a step into oblivion.

Consider, for example, the whole Stata vs Stan thing.  All of a sudden, we’re looking like chumps. Sure, we’re faster and more scalable than Stata, but our notation makes it look like you need a dual PhD in stat and CS to write a model.

A

[Michael Betancourt]

Hey, if people want to limit the language so that everything is a pdf or that we never need a Jacobian then go ahead.  But all of this talk about making the language harder to read is BS -- all we are doing is making the existing ambiguities explicit.  Expressiveness vs simplicity is a fundamental trade-off made only trickier by the subtleties of probability theory.

[Andrew Gelman]

No, it’s not B.S.  

Comparing this:

model {
  target += normal_lpdf(alpha | 0, 10);
  target += normal_lpdf(beta | 0, 2);
  target += cauchy_lpdf(sigma | 0, 2.5);
  target += normal_lpdf(y | alpha * x + beta, sigma);
}

to this:

model {
 @ normal(alpha | 0, 10);
 @ normal(beta | 0, 2);
 @ cauchy(sigma | 0, 2.5);
 @ normal(y | alpha * x + beta, sigma);
}

is a big difference.

The first code snippet is hard to read, hard to write, and easy to typo.  Not everything in the language is a pdf, but most things are, and that’s one of the points of having a default.  I really think the top code snippet is a disaster.

I _do_ think we should change our notation, I _do_ think the current Bugs-like notation is confusing because it implies something else, and I _do_ think we can do it without cluttering our code with “target” and “_lpdf”.

[Michael Betancourt]

It’s simpler because you chose a model that’s so easy there

is no confusion!  Add some nonlinear transformations to LHS

or any of the distributions, or try to add a discrete distribution

over parameters to the target.  The @ notation has no intuition

and absolutely no context.  Defaulting to log pdfs makes the

notation symmetric and hides what’s really going on. 

The first is not hard to read, the additional time needed to write

it and potential for typos is minimal, especially with automatic

code completion.

[Andrew Gelman]

1.  Create a harder model and let’s try it out in alternative notations and see what it looks like.

2.  I disagree with your claim, “The first is not hard to read, the additional time needed to write it and potential for typos is minimal, especially with automatic code completion.”  In CloudStan, maybe, because the interface could put “target” and “_lpdf” in some alternative color and even a smaller font.  But we’re often writing models in plain text, or putting them in papers, or emailing them to people, and this “target…_lpdf” thing makes the model look about as accessible and appealing as a Form 1040.

[Dustin Tran]

Just to add another example, I attached a picture of how I currently have to specify probability models, when building algorithms to test in native Python.

It looks a lot like what the _lpdf stuff will look. Interface-wise, it is a pain in the butt and it’s also hard to read and debug. I do like the explicitness of what it’s doing though, but maybe the abstraction is worth it?

Dustin

[Ben Goodrich]

On Wednesday, January 27, 2016 at 11:04:40 PM UTC-5, Andrew Gelman wrote:

I’m with Eric.  To me, the _lpdf thing is close to a deal-breaker.  Almost everything we are using is an lpdf.  I hadn’t thought so much about it, but seeing Eric’s example, I agree that it’s a lot less user friendly, it’s just a pain in the ass.

I think to defend normal(y | mu, sigma) over normal_lpdf(y | mu, sigma) you would have to be okay with the fact that a lot of users wouldn't actually know that normal(y | mu, sigma) means "the log of the normal PDF" even though almost everything we are using in Stan programs is a log-PDF. If most everyone knew that, then I think the case for typing something shorter would be stronger. But I would guess at least 1 / 3 of users don't know that. So, I think brevity is not a luxury we can afford. It's the same thing with @ vs target +=.
 

Consider, for example, the whole Stata vs Stan thing.  All of a sudden, we’re looking like chumps. Sure, we’re faster and more scalable than Stata, but our notation makes it look like you need a dual PhD in stat and CS to write a model.

Currently, I would say that Stan succeeds despite its language rather than because of it. The Stan language allows you to express a ton of things, but each individual user is usually only expressing a thin slice of that. For a lot of users, even writing code in a domain-specific language is something they endure in order to use Stan's algorithms, rather than something they think is a good way of expressing models. It will continue to be that way if we change the language to be more pedantic but hopefully more people will think about what target += normal_lpdf(y | mu, sigma) means in the language.

Ben

[Krzysztof Sakrejda]

I like the Stan language because it lets me express a probabilistic model without much ambiguity while automating the numerical stuff. I know other people appreciate the BUGS-like veneer it places over MCMC. Maybe if we want BUGS level of simplicity, we should do a language subset that deals only in graphical models and either keep the ~ syntax or use @ for that. If we did an rStanBUGS interface I'm sure we could nab a bigger user base...

[Michael Betancourt]

+1

[Jonah Gabry]

On Wednesday, January 27, 2016 at 10:25:01 PM UTC-5, Eric Novik wrote:
> My $0.000002:
>

And I thought you were Negotiator Novik. That's 1/500000 of a dollar. You couldn't even buy a bread crumb in the middle ages with 1/500000 of a current USD.

On Wednesday, January 27, 2016 at 10:25:01 PM UTC-5, Eric Novik wrote:
> On the larger issue, I totally get that the proposed notation is closer to the underlying machinery of Stan, but is it worth pissing off a lot of Stan users who invested time in learning the current notation? Again, quoting Bob:
>
> I think the whole thing looks ugly, and said so
> at the meeting.  I'm extremely apprehensive about
> this change.  I worry it's going to confuse and
> alienate our users (not that they weren't confused
> before --- that's what the change is for --- to unconfuse
> them).  And I know it's going to piss off everyone who's put
> effort into code and doc for the existing system.
>

I'm finding it very difficult to figure out where I stand on this issue.

On one hand, I completely agree with Michael (and others) about the value of making existing ambiguities explicit. On the other hand, like Bob says, I am also quite worried that we risk alienating many current and future users, and I do think the proposed changes to the language are quite hideous from an aesthetic point of view. I agree with Michael that I don't think they will make Stan programs _harder_ to read, but I do think they make them uglier. But how much value we should place in aesthetics I'm really not sure.

I wonder if it would be helpful (or at a minimum interesting) to ask current users for feedback on these proposed changes. I'm not at all proposing that we blindly do what current users want, but we're hypothesizing about their reactions without really asking.

[Ben Goodrich]

On Thursday, January 28, 2016 at 12:03:43 PM UTC-5, Jonah Gabry wrote:

I wonder if it would be helpful (or at a minimum interesting) to ask current users for feedback on these proposed changes. I'm not at all proposing that we blindly do what current users want, but we're hypothesizing about their reactions without really asking.

I'm pretty sure the vast majority of responders would prefer that the language not change at all, and those that want the language to change would want it to become a graphical modeling language.

Maybe a broader question is: Who is the Stan language primarily intended for? The Julia and especially the Python people don't really like the Stan language anyway because it is domain-specific, so at least some of them just reimplement NUTS. And I think it is telling that McElreath's book is subtitled "A Bayesian Course with Examples in R and Stan" but the nearly 500 page text has exactly 1 full Stan program and 1 fragment of a model block, both of which are set off in Overthinking boxes. Stan's algorithms are used a ton in the book's examples but via the statistical-ish syntax defined in the rethinking package, which generates a Stan program that the user typically does not see. So, it would appear as if Richard believes that diving into the Stan language is not the best way to learn Bayesian inference for his target audience, which is firstly biology Ph.D. students. And I definitely felt that diving into the Stan language is not the best way for the QMSS students to learn Bayesian inference; they need to start with rstanarm.

So, I don't think the current Stan language is suitable for everybody, but the question is whether we should change it, and if so should it go in the direction of making it easier for people without a lot of training or easier for power-users? I'm not sure the proposed changes accomplish either, but I hope they expose and perhaps discourage misconceptions about what is being expressed.  Of course, people like their misconceptions, so they will complain and / or turn to something where they don't have to write models in the Stan language. But I'm a bit skeptical about trying to make the language easier for people without a lot of training because I think the main hurdle such people face is the concept of fully specifying a model, rather than they have a fully-specified model in their head and have great difficulty typing it in a probabilistic programming language.

Ben

[Allen B. Riddell]

My 2cents: I really like the notation:

model {
@ normal(alpha | 0, 10);
@ normal(beta | 0, 2);
@ cauchy(sigma | 0, 2.5);
@ normal(y | alpha * x + beta, sigma);
}

Also, can't we support both and have the simpler version be a clearly
defined use of syntactic sugar?

> >>>> >> https://github.com/stan-dev/stan/wiki/Stan-3-Density-Notation-and-Increments <https://github.com/stan-dev/stan/wiki/Stan-3-Density-Notation-and-Increments>

> >>>> >>
> >>>> >> I translated some models at the end. Some of these look pretty
> >>>> >> ugly in their original form, too.
> >>>> >>
> >>>> >> - 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.
> >>>> > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >>>>
> >>>> --
> >>>> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.
> >>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >>>>
> >>>>
> >>>> --
> >>>> 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 <mailto:stan-dev+u...@googlegroups.com>.
> >>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >>>
> >>>
> >>> --
> >>> 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 <mailto:stan-dev+u...@googlegroups.com>.
> >>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >>>
> >>>
> >>> --
> >>> 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 <mailto:stan-dev+u...@googlegroups.com>.
> >>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >>
> >>
> >> --
> >> 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 <mailto:stan-dev+u...@googlegroups.com>.
> >> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

> >
> >
> > --
> > 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 <mailto:stan-dev+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Bob Carpenter]

> On Jan 28, 2016, at 1:40 PM, Ben Goodrich <goodri...@gmail.com> wrote:
>
> On Thursday, January 28, 2016 at 12:03:43 PM UTC-5, Jonah Gabry wrote:
> I wonder if it would be helpful (or at a minimum interesting) to ask current users for feedback on these proposed changes. I'm not at all proposing that we blindly do what current users want, but we're hypothesizing about their reactions without really asking.
>
> I'm pretty sure the vast majority of responders would prefer that the language not change at all, and those that want the language to change would want it to become a graphical modeling language.

Absolutely. No need to ask the users. This is a "we're
doing it for your own good" sort of thing that nobody's going
to respond well to. That's what worries me.

Why do you think people would want it to become a graphical
modeling language? Because it removes order dependencies?

> Maybe a broader question is: Who is the Stan language primarily intended for?

I think that's a very good question to frame this discussion.

> The Julia and especially the Python people don't really like the Stan language anyway because it is domain-specific, so at least some of them just reimplement NUTS.

They don't like it because it's not an *embedded* domain-specific
language --- it's external.

If you look at something like PyMC, it's absolutely something
you need to learn. It's a library of objects and ways they
interact to form graphical models. It's not like emcee, where
you just write down your density as a Python function. I'm going
to peel off what I had about PyMC into another post.

> And I think it is telling that McElreath's book is subtitled "A Bayesian Course with Examples in R and Stan" but the nearly 500 page text has exactly 1 full Stan program and 1 fragment of a model block, both of which are set off in Overthinking boxes. Stan's algorithms are used a ton in the book's examples but via the statistical-ish syntax defined in the rethinking package, which generates a Stan program that the user typically does not see. So, it would appear as if Richard believes that diving into the Stan language is not the best way to learn Bayesian inference for his target audience, which is firstly biology Ph.D. students. And I definitely felt that diving into the Stan language is not the best way for the QMSS students to learn Bayesian inference; they need to start with rstanarm.

We've also heard from other people trying to teach that Stan's
too hard so they reverted to BUGS.

I was very surprised by the tack taken in Richard's book.

When someone writes down their first RStanARM expression, what
are you expecting them to know? Do you want them to understand
the relation between the RStanARM expression and the density it
expresses? That's the first thing I'd want to know about it as
a user, but then I'm probably not a typical user here.

> So, I don't think the current Stan language is suitable for everybody, but the question is whether we should change it, and if so should it go in the direction of making it easier for people without a lot of training or easier for power-users?

Exactly the right question. I personally feel very strongly that **for Stan**
we should prioritize making hard things possible (like those LKJ priors)
over making easy things easier (like easy notation for regression models).

And by Stan, I mean the language and solvers, not all the wrappers. Those
can encapsulate all they want and spend the effort to make easy things
even easier. It's the same argument as making something that takes one minute
take 5 seconds --- you can explore more options and use that time doing
something else.

> I'm not sure the proposed changes accomplish either, but I hope they expose and perhaps discourage misconceptions about what is being expressed.

That's the only upside. It's not like the existing thing is imprecise,
just that it's misunderstood.

This change will definitely drive home the point that we're just incrementing
something.

> Of course, people like their misconceptions, so they will complain and / or turn to something where they don't have to write models in the Stan language. But I'm a bit skeptical about trying to make the language easier for people without a lot of training because I think the main hurdle such people face is the concept of fully specifying a model, rather than they have a fully-specified model in their head and have great difficulty typing it in a probabilistic programming language.

I agree that's the main hurdle people face in learning modeling.

For me, BUGS was instrumental in my learning the basics
of modeling. It makes the models absolutely concrete in a way
that they never are in narrative stats papers or books.

My goal for Stan all along is to make it easy for people to write
down densities. Especially for more complex models. That hasn't
succeeded on all fronts, but that's my goal.

The indirection of lmer() left me confused while reading Gelman and
Hill, and it wasn't until much later that I learned what the marginalization,
optimization, and then second optimization were doing. It was
all just magic (opaque/black-box) to me, which I don't like as a computer
scientist.

A bigger point is that learners have different styles and what
we probably want to do is provide angles for everyone to get up to
speed. Obviously Ben and Jonah think it's important --- they spent
all that time building RStanArm.

- Bob

[Bob Carpenter]

Yes, and we could have

alpha ~ normal(0, 10);

as even sweeter sugar (more saccharine)!

I think the point was that people wanted to make it explicit
that there is a function evaluation and increment going on,
not something that could be confused with random-number generation.

- Bob

[Ben Goodrich]

On Thursday, January 28, 2016 at 2:48:55 PM UTC-5, Bob Carpenter wrote:

When someone writes down their first RStanARM expression, what
are you expecting them to know?  Do you want them to understand
the relation between the RStanARM expression and the density it
expresses?  That's the first thing I'd want to know about it as
a user, but then I'm probably not a typical user here.

I would say that if a user is calling stan_foo() in rstanarm, then they are assumed to understand how to call foo() and what foo() is used for. Ideally, they would also understand the likelihood function underlying foo() --- and thus stan_foo() --- and the generative model that implies the likelihood, but I think there's a lot of people out there who "know" that a logit model is what you do when your outcome is binary but don't know that a logit model is a Bernoulli likelihood where the probability of success is a standard logistic CDF applied to the linear predictor, etc. At first, we aren't expecting them to understand / change the priors. We really want them to learn all the Bayesian stuff that comes after you get the draws. Then, hopefully they can apply all that when they start writing in the Stan language.

Ben

[Allen B. Riddell]

I get that. So I'd support giving a deprecation warning (not error) if
someone uses:

alpha ~ normal(0, 10);

I think the change to the new functions is a good one. Explicit is
better than implicit.

[Andrew Gelman]

I think explicit is better than implicit too. But I think the following _is_ explicit:

model {
@ normal(alpha | 0, 10);
@ normal(beta | 0, 2);
@ cauchy(sigma | 0, 2.5);
@ normal(y | alpha * x + beta, sigma);
}

I also think it would fine to allow “target +=“ and to allow “_lpdf”, I just don’t think they should be required as they make models horrible.

[Andrew Gelman]

As we’ve discussed, I think the notation

alpha ~ normal(0, 10);

is harder to follow than

@ normal(alpha | 0, 10);

I’m happy to discuss at the meeting why I say this.

A

[Bob Carpenter]

By "explicit", I meant explicitly indicating a sum.

y ~ normal(mu, sigma);

@ normal(y | mu, sigma);

target += normal_lpdf(y | mu, sigma);

From my vantage, only the last one supplies that.

- Bob

[Andrew Gelman]

I’d be ok with << if this looks more explicit. Actually, I like += too, but I do agree with Eric that there’s something bothersome about having “target” on each line, over and over again. It really will make the code harder to read and more annoying to write.

[Jonah Sol Gabry]

On Thu, Jan 28, 2016 at 6:11 PM, Andrew Gelman <gel...@stat.columbia.edu> wrote:

there’s something bothersome about having “target” on each line, over and over again.  

How about "walmart"? You know, as in 

walmart += normal_lpdf(y | mu, sigma)

[Allen B. Riddell]

Can't we just say, at every opportunity that, '@' *means* "target += "
and implies that the _lpdf may be omitted? (And it's the only situation
where it can be omitted.) I would also imagine that writing

@ normal_lpdf(y| mu, sigma)

would be a syntax error.

[Andrew Gelman]

Defining it as an explicit shortcut works for me.

[Jonah Sol Gabry]

Maybe that's a good compromise. 

Not to poop on the party, but isn't having the shortcut and the real way basically where we're at with sampling notation vs increment_log_prob?

Some other questions to think about if we encourage (or at least don't actively discourage) the shortcut:

Would the Stan manual use the shortcut or just mention that it exists and use the long (real) way? If the manual uses the real, long notation then the code in manual will look different from how most users write their models. It would be hard to ignore the shortcut but having the explicit full version is kind of the point to all this, so it would be odd to then not use it. Or are we just going to switch back and forth at whim?

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

[Andrew Gelman]

> On Jan 28, 2016, at 8:32 PM, Jonah Sol Gabry <jga...@gmail.com> wrote:
>
> Maybe that's a good compromise.
>
> Not to poop on the party, but isn’t having the shortcut and the real way basically where we're at with sampling notation vs increment_log_prob?

Yes, but I think the ~ notation is actively confusing in that it looks like Stan is drawing a random sample. I like the idea that we’re computing increments of the log target.

[Jiqiang Guo]

I am having an idea, which is neat in a way but it's less explicit.  I am just thinking every statement has a value that will be added to the log-posterior unless we somehow say this statement does not.  

The following are two different examples:  the first one does not contribute to the posterior, but it changes the value of alpha; the second one adds to the posterior. 

alpha = alpha0 + delta, 0;

normal(alpha | mu, sigma); 

Jiqiang 

[Andrew Gelman]

I thought of this idea too, and I like it, but I thought it could be confusing to users and it could invite errors.  I liked the @ because it is a clear signal that something is happening.  Or <<, but to me << wasn’t so appealing because it looks like “less than”.

[Ben Goodrich]

On Thursday, January 28, 2016 at 7:37:05 PM UTC-5, Allen B. Riddell wrote:

Can't we just say, at every opportunity that, '@' *means* "target += "
and implies that the _lpdf may be omitted? (And it's the only situation
where it can be omitted.) I would also imagine that writing

@ normal_lpdf(y| mu, sigma)

would be a syntax error.

If @ means target +=, then I don't see why we would need to support target +=. I don't hate the @ syntax, but it only vaguely hints of addition and only vaguely hints that there is some target that is being aimed at. So, if you know those things, then it might make sense. But y ~ normal(mu, sigma) currently means that and people get confused by it, so I don't know if such people will be less confused by @normal(y| mu, sigma).

Ben
 

> >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.

> >>>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

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

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

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

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

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

> >>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> >>>>>
> >>>>> --
> >>>>> 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/d/optout.
> >>>>
> >>>> --
> >>>> 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/d/optout.
> >>>>
> >>>>
> >>>
> >>> --
> >>> 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/d/optout.
> >>
> >> --
> >> 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/d/optout.
> >
> >
> > --
> > 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/d/optout.
> >
> >
>
> --
> 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.

[Andrew Gelman]

My problems with y ~ are:

(a) it looks like Bugs and thus can be confusing.  Not a long-term issue, perhaps, but currently it is an issue.

(b) It looks like random sampling is being done, which isn’t happening.

(c) even setting aside item (b), it looks like something is being done to y, which isn’t.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Aki Vehtari]

I find it interesting that in BDA there is no connection with ~ and sampling, but Stan manual refers to ~ with "sampling statement". I couldn't easily find where the term "sampling statement" is first time defined in Stan manual, although it's used a lot. I've been so used to think that ~ refers to distributions that I didn't realize this before, but now I don't wonder at all if someone reading the Stan manual gets the impression that ~ implies sampling from the given distribution.

Aki

> > >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.

>
> > >>>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

>
> > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>> --
>
> > >>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>> --
>
> > >>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>> --
>
> > >>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>> --
>
> > >>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>
>
> > >>>>> --
>
> > >>>>> 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.
>
> > >>>>
>
> > >>>> --
>
> > >>>> 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.
>
> > >>>>
>
> > >>>>
>
> > >>>
>
> > >>> --
>
> > >>> 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.
>
> > >>
>
> > >> --
>
> > >> 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.
>
> > >
>
> > >
>

[Allen B. Riddell]

Maybe the compromise here is to confuse beginners in equal degrees (y ~
normal(...) vs. @ normal(y|..)) and to improve the clarity of the
language for advanced users?

> > it, send an email to stan-dev+u...@googlegroups.com <mailto:

> > stan-dev%2Bunsu...@googlegroups.com>.
> > > >>>>>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> 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 <mailto:

> > stan-dev%2Bunsu...@googlegroups.com>.
> > > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> 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 <mailto:
> > stan-dev+u...@googlegroups.com>.

> > > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> 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 <mailto:
> > stan-dev+u...@googlegroups.com>.

> > > >>>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> 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 <mailto:
> > stan-dev+u...@googlegroups.com>.

> > > >>>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> 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 <mailto:
> > stan-dev+u...@googlegroups.com>.

> > > >>>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> 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 <mailto:
> > stan-dev+u...@googlegroups.com>.

> > > >>>>>> For more options, visit https://groups.google.com/d/optout <
> > https://groups.google.com/d/optout>.
> > > >>>>>
> > > >>>>> --
> > > >>>>> 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.
> > > >>>>
> > > >>>> --
> > > >>>> 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.
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> --
> > > >>> 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.
> > > >>
> > > >> --
> > > >> 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.
> > > >
> > > >
> > > > --
> > > > 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.
> > > >
> > > >
> > >
> > > --
> > > 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.

[Krzysztof Sakrejda]

On Thursday, January 28, 2016 at 9:49:34 PM UTC-5, Ben Goodrich wrote:
> On Thursday, January 28, 2016 at 7:37:05 PM UTC-5, Allen B. Riddell wrote:Can't we just say, at every opportunity that, '@' *means* "target += "
>
> and implies that the _lpdf may be omitted? (And it's the only situation
>
> where it can be omitted.) I would also imagine that writing
>
>
>
> @ normal_lpdf(y| mu, sigma)
>
>
>
> would be a syntax error.
>
>
>
> If @ means target +=, then I don't see why we would need to support target +=.

Because models that use non-standard distributions will end up looking like this:

...
real target;
...
target <- target + ... + ... + ...
...
target <- target + ...
...
@target

That's fine I guess, but @ is no intuitive in any sense for incrementing a target density. Let's not make one of the main points we have to explain to people obscure, unless we're going to go whole-hog and do rstanarm/rstanBUGS interfaces.

> > >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.

>
> > >>>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

>
> > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>> --
>
> > >>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>> --
>
> > >>>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>> --
>
> > >>>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>> --
>
> > >>>>>> 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 <mailto:stan-dev+u...@googlegroups.com>.

>
> > >>>>>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> > >>>>>
>
> > >>>>> --
>
> > >>>>> 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.
>
> > >>>>
>
> > >>>> --
>
> > >>>> 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.
>
> > >>>>
>
> > >>>>
>
> > >>>
>
> > >>> --
>
> > >>> 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.
>
> > >>
>
> > >> --
>
> > >> 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.
>
> > >
>
> > >
>
> > > --
>
> > > 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.
>
> > >
>
> > >
>
> >
>
> > --
>
> > 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.