Open alashworth opened 5 years ago
Comment by suhailshergill
Wednesday Jun 15, 2016 at 11:12 GMT
responding to @andrewgelman 's comment on #1917
... but as we've been taking about the verbose parser that picks up possible errors, it strikes me that this is another thing that we can add: certain if/else statements that are bad news for HMC.
would the functions listed in section 32.6 of the manual also be suited for a similar compiler warning (i currently don't have access to a machine with Stan installed and as such am unclear what Stan's current behaviour is)?
@andrewgelman could you or @bob-carpenter point me to some of the other known "possible error" scenarios? let me know if it would be preferred for me to reach out on the mailing list with that.
Comment by bob-carpenter
Wednesday Jun 15, 2016 at 15:22 GMT
I updated the issue to reflect the problem with step-like functions. We should also warn about and/or deprecate these when applied to parameters.
P.S. General discussion should go on the list, but issue-specific comments are fine here.
Comment by VMatthijs
Thursday Dec 13, 2018 at 13:17 GMT
Is this still desired? Might be cool to add to stanc3?
Comment by bob-carpenter
Thursday Dec 13, 2018 at 14:09 GMT
This should go into a lint mode, not into the default parser.
verbose parser that picks up possible errors, it strikes me that this is another thing that we can add: certain if/else statements that are bad news for HMC.
The conditions in question are ones involving parameters, which don't necessarily make something nondifferentiable (e.g., with proper interpolation), so it's just a warning with possible false positives, hence it should go in the lint mode.
On Dec 13, 2018, at 8:17 AM, Matthijs Vákár notifications@github.com wrote:
Is this still desired? Might be cool to add to stanc3?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Comment by VMatthijs
Thursday Dec 13, 2018 at 15:10 GMT
Agreed! It shouldn't be hard, as the semantically checked AST is decorated with the information that an expression depends on parameters.
Summary:
Want to alert users that disconinuities can cause problems, specifically:
Description:
Just a warning for now. Plus documentation in the manual trying to make it clearer why this is a problem.
For the step-like functions, the manual now says:
Warning: These functions can seriously hinder sampling and optimization efficiency for gradient-based methods (e.g., NUTS, HMC, BFGS) if applied to parameters (includ- ing transformed parameters and local variables in the transformed parameters or model block). The problem is that they break gradients due to discontinuities coupled with zero gradients elsewhere. They do not hinder sampling when used in the data, transformed data, or generated quantities blocks.
Conditioning on a parameter is just another way of creating a step-like function.
Reproducible Steps:
This came up with an example from @suhailshergill on issue https://github.com/stan-dev/stan/issues/1917#issuecomment-225755891
It also comes up when users try to write iterative algorithms that depend on a parameter, though these are sometimes OK as are things like interpolation models.
Current Output:
No warning, failing to mix at sampler level.
Expected Output:
Warning from Stan compiler
Current Version:
v2.9.0