I started the Stan Parser Pedantic Mode page

[Andrew Gelman]

Hi all. Mike set up the page and I started it off; see here:
https://github.com/stan-dev/stan/wiki/Stan-Parser-Pedantic-Mode
I think we had a bunch of other things to add to the list but I can't remember them right now.
A

[Bob Carpenter]

Most of these are going to have to be built into the parser
code itself to do it right, especially given the creative
syntax we see from users.

I don't know if the "sigma..." thing is worth doing. Not
many of our users use "sigma" or "sigma_foo" the way Andrew does. And
presumably you meant should have <lower=0> in its declaration?
It probably got lost in the markdown.

Do we also flag normal(0, 1000) and other attempts at very
diffuse priors?

The problem with a lot of this is that we'll have to be
doing simple blind matching. Most of our users don't
use "sigma" (or "tau" the way Andrew does). Nor do they
follow the sigma_foo standard---it's all over the place.

We can pick up literal values (and by literal, I mean
it's a number in the code). We won't be able to pick up
more complex things like gamma(a, b) where a < 1 and b < 1,
because that's a run-time issue, not a compile-time issue,
for instance if a and b are data.

Should we also flag <lower=A> if A != 0 or A!= -1? (Again,
we'll be able to pick up literal numbers there, not more
complex violations).

Conditionals (if-else) are only problematic if the conditions
depend on parameters.

Everyone wants to do more complicated things, like make sure
that if a variable is given a distribution with a bound that the
bound's declared in the parameters. So no:

real alpha;

alpha ~ lognormal(...)

because then alpha isn't well defined. These things are going to
be a lot of work to track down and we'll again only be able to pick
out direct cases like this.

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

[Michael Betancourt]

I’m thinking of a -pedantic flag to the parser, which we
can then call through the interfaces in various ways,
so it would make sense to built everything up in the
parser itself.

I tried to stress at the meeting that we need not just
notions of what to check for but explicit patterns and
I think that got lost in my bad connections. Maybe
have a second section on the Wiki with explicit
patterns to match with corresponding warning text
that can then be integrated into the parser?

[Bob Carpenter]

The patterns in question are complex syntactic relationships
in some clases, like the link between a variable's declaration
and use.

If we start cluttering up the parser trying to do all this on
the fly, things could get very ugly (in the code) very fast,
as the underlying parser's just a huge pain to work with.

- Bob

[Michael Betancourt]

So what’s the best place to introduce these checks?
It’s not dissimilar for what’s already done with the
Jacobian checks, no?

[Bob Carpenter]

> On Jun 22, 2016, at 1:03 AM, Michael Betancourt <betan...@gmail.com> wrote:
>
> So what’s the best place to introduce these checks?
> It’s not dissimilar for what’s already done with the
> Jacobian checks, no?

It depends what they are. I should've been clearer that
I meant on the fly as in find the issue as it's parsing.

There are two approaches --- plumb enough information top
down through the parser so that we can check inside of
a single expression or statement --- that's what the Jacobian
check does now. To do that, the source of every variable
needs to be plumbed through the entire parse tree. If we do
more of that it's going to get ugly. Some of these are
"peephole" warnings --- things you can catch just locally.

For others, we have the AST and can design walkers for it
that walk over the code any old way and report.

Or, we could do something hacky with regexes along the
lines of cpplint (a Python program, not something plumbed into
the C++ parser, at least as far as I know).

[Andrew Gelman]

Hi, Mike. Of course we need explicit patterns but these will correspond to conceptual errors. I think it makes sense to list the conceptual errors in any case, and also to list the explicit patterns. I can't remember all the possibilities offhand.
A

[Andrew Gelman]

HI, I've put many of these comments on to the wikipage since that might be easier than a long email thread. My short answer to Bob's question is that I'm happy to flag "sigma" parameters that are unconstrained, _unless_ we find that lots of people are using "sigma" for regression coefficients or whatever. I'm not expecting the parser to catch all errors; I just want to catch some. And, yes, I understand the issue with gamma(a,b) if a and b are parameters. Again, I'm happy to catch the things we can catch; I still think this will be a step forward. Hell, if all we do is catch uniform priors and inverse-gamma(.001,.001), we're already ahead of the game.
A

[Bob Carpenter]

We can do both of those easily in the parser. I agree that
those are probably a bigger deal than sigma, because
not many people use variables named sigma. Odd, because
I'd have thought they'd follow our conventions, which are pretty
regular and based on your books, but they're taking conventions
from all over the place, which makes sense.

- Bob