34.3 Pedantic mode
Pedantic mode is a compilation option built into Stanc3 that warns you about potential issues in your Stan program.
For example, consider the following program.
data {
int N;
array[N] real x;
}parameters {
real sigma;
}model {
real mu;
x ~ normal(mu, sigma); }
When pedantic mode is turned on, the compiler will produce the following warnings.
Warning:
The parameter sigma has no priors.
Warning at 'ped-mode-ex1.stan', line 10, column 14 to column 16:
The variable mu may not have been assigned a value before its use.
Warning at 'ped-mode-ex1.stan', line 10, column 18 to column 23:
A normal distribution is given parameter sigma as a scale parameter
(argument 2), but sigma was not constrained to be strictly positive.
Here are the kinds of issues that pedantic mode will find (which are described in more detail in following sections):
- Distribution usages issues. Distribution arguments don’t match the distribution specification, or some specific distribution is used in an inadvisable way.
- Unused parameter. A parameter is defined but doesn’t contribute to target.
- Large or small constant in a distribution. Very large or very small constants are used as distribution arguments.
- Control flow depends on a parameter. Branching control flow (like if/else) depends on a parameter value .
- Parameter has multiple tildes. A parameter is on the left-hand side of multiple tildes.
- Parameter has zero or multiple priors. A parameter has zero or more than one prior distribution.
- Variable is used before assignment. A variable is used before being assigned a value.
- Strict or nonsensical parameter bounds. A parameter is given questionable bounds.
- Nonlinear transformations. When the left-hand side of a tilde statement (or first argument of a log probability function) contains a nonlinear transform which may require a Jacobian change of variables adjustment.
Some important limitations of pedantic mode are listed at the end of this chapter.
34.3.1 Distribution argument and variate constraint issues
When an argument to a built-in distribution certainly does not match that
distribution’s specification in the Stan Functions
Reference, a warning
is thrown. This primarily checks if any distribution argument’s bounds at
declaration, compile-time value, or subtype at declaration (e.g. simplex
) is
incompatible with the domain of the distribution. x
For example, consider the following program.
parameters {
real unb_p;
real<lower=0> pos_p;
}model {
1 ~ poisson(unb_p);
1 ~ poisson(pos_p);
}
The parameter of poisson
should be strictly positive, but unb_p
is not constrained to be positive.
Pedantic mode produces the following warning.
Warning at 'ex-dist-args.stan', line 6, column 14 to column 19:
A poisson distribution is given parameter unb_p as a rate parameter
(argument 1), but unb_p was not constrained to be strictly positive.
34.3.2 Special-case distribution issues
Pedantic mode checks for some specific uses of distributions that may indicate a statistical mistake:
34.3.2.1 Uniform distributions
Any use of uniform distribution generates a warning, except when the variate
parameter’s declared upper
and lower
bounds exactly match the uniform
distribution bounds. In general, assigning a parameter a uniform distribution
can create non-differentiable boundary conditions and is not recommended.
For example, consider the following program.
parameters {
real a;
real<lower=0, upper=1> b;
}model {
0, 1);
a ~ uniform(0, 1);
b ~ uniform( }
a
is assigned a uniform distribution that doesn’t match its constraints.
Pedantic mode produces the following warning.
Warning at 'uniform-warn.stan', line 6, column 2 to column 20:
Parameter a is given a uniform distribution. The uniform distribution is
not recommended, for two reasons: (a) Except when there are logical or
physical constraints, it is very unusual for you to be sure that a
parameter will fall inside a specified range, and (b) The infinite gradient
induced by a uniform density can cause difficulties for Stan's sampling
algorithm. As a consequence, we recommend soft constraints rather than hard
constraints; for example, instead of giving an elasticity parameter a
uniform(0, 1) distribution, try normal(0.5, 0.5).
34.3.2.2 (Inverse-) Gamma distributions
Gamma distributions are sometimes used as an attempt to assign an improper prior to a parameter. Pedantic mode gives a warning when the Gamma arguments indicate that this may be the case.
34.3.2.3 lkj_corr distribution
Any use of the lkj_corr
distribution generates a warning that suggests using
the Cholesky variant instead. See
https://mc-stan.org/docs/functions-reference/correlation_matrix_distributions.html#lkj-correlation for details.
34.3.3 Unused parameters
A warning is generated when a parameter is declared but does not have any effect
on the program. This is determined by checking whether the value of the target
variable depends in any way on each of the parameters.
For example, consider the following program.
parameters {
real a;
real b;
}model {
1, 1);
a ~ normal( }
a
participates in the density function but b
does not.
Pedantic mode produces the following warning.
Warning:
The parameter b was declared but was not used in the density calculation.
34.3.4 Large or small constants in a distribution
When numbers with magnitude less than 0.1 or greater than 10 are used as arguments to a distribution, it indicates that some parameter is not scaled to unit value, so a warning is thrown. See https://mc-stan.org/docs/stan-users-guide/efficiency-tuning.html#standardizing-predictors-and-outputs for a discussion of scaling parameters.
For example, consider the following program.
parameters {
real x;
real y;
}model {
100, 100);
x ~ normal(-0, 1);
y ~ normal( }
The constants -100
and 100
suggest that x
is not unit scaled.
Pedantic mode produces the following warning.
Warning at 'constants-warn.stan', line 6, column 14 to column 17:
Argument -100 suggests there may be parameters that are not unit scale;
consider rescaling with a multiplier (see manual section 22.12).
Warning at 'constants-warn.stan', line 6, column 19 to column 22:
Argument 100 suggests there may be parameters that are not unit scale;
consider rescaling with a multiplier (see manual section 22.12).
34.3.5 Control flow depends on a parameter
Control flow statements, such as if
, for
and while
should not depend on
parameters or functions of parameters to determine their branching conditions.
This is likely to introduce a discontinuity into the density function. Pedantic
mode generates a warning when any branching condition may depend on a parameter
value.
For example, consider the following program.
parameters {
real a;
}model {
// x depends on parameter a
real x = a * a;
int m;
// the if-then-else depends on x which depends on a
if(x > 0) {
//now m depends on x which depends on a
1;
m = else {
} 2;
m =
}
// for loop depends on m -> x -> a
for (i in 0:m) {
1);
a ~ normal(i,
} }
The if
and for
statements are control flow that depend (indirectly) on the value of the parameter m
.
Pedantic mode produces the following warning.
Warning at 'param-dep-cf-warn.stan', line 11, column 2 to line 16, column 3:
A control flow statement depends on parameter(s): a.
Warning at 'param-dep-cf-warn.stan', line 19, column 2 to line 21, column 3:
A control flow statement depends on parameter(s): a.
34.3.6 Parameters with multiple tildes
A warning is generated when a parameter is found on the left-hand side of more than one ~ statements (or an equivalent target +=
conditional density statement). This pattern is not inherently an issue, but it is unusual and may indicate a mistake.
Pedantic mode only searches for repeated statements, it will not for example generate a warning when a ~ statement is executed repeatedly inside of a loop.
For example, consider the following program.
data {
real x;
}parameters {
real a;
real b;
}model {
0, 1);
a ~ normal(1);
a ~ normal(x,
1, 1);
b ~ normal( }
Pedantic mode produces the following warning.
Warning at 'multi-tildes.stan', line 9, column 2 to column 19:
The parameter a is on the left-hand side of more than one tildes
statement.
34.3.7 Parameters with zero or multiple priors
A warning is generated when a parameter appears to have greater than or less than one prior distribution factor.
This analysis depends on a factor graph representation of a Stan program. A factor F that depends on a parameter P is called a prior factor for P if there is no path in the factor graph from F to any data variable except through P.
One limitation of this approach is that the compiler cannot distinguish between modeled data
variables and other convenient uses of data
variables such as data sizes or hyperparameters. This warning assumes that all data variables (except for int
variables) are modeled data, which may cause extra warnings.
For example, consider the following program.
data {
real x;
}parameters {
real a;
real b;
real c;
real d;
}model
{0, 1); // this is a prior
a ~ normal(1); // this is not a prior, since data is involved
x ~ normal(a,
1); // this is also not a prior, since data is involved
b ~ normal(x,
// this is not a prior for c, since data is involved through b
// but it is a prior for b, since the data is only involved through b
1);
c ~ normal(b,
//these are multiple priors:
0, 1);
d ~ normal(1 ~ normal(d, 1);
}
One prior is found for a
and for b
, while c
only has a factor that touches a data
variable and d
has multiple priors.
Pedantic mode produces the following warning.
Warning:
The parameter c has no priors.
Warning:
The parameter d has 2 priors.
34.3.8 Variables used before assignment
A warning is generated when any variable is used before it has been assigned a value.
For example, consider the following program.
transformed data {
real x;
if (1 > 2) {
1;
x = else {
} print("oops");
}print(x);
}
Since x
is only assigned in one of the branches of the if
statement, it might get to print(x)
without having been assigned to.
Pedantic mode produces the following warning.
Warning at 'uninit-warn.stan', line 7, column 8 to column 9:
The variable x may not have been assigned a value before its use.
34.3.9 Strict or nonsensical parameter bounds
Except when there are logical or physical constraints, it is very unusual for you to be sure that a parameter will fall inside a specified range. A warning is generated for all parameters declared with the bounds <lower=.., upper=..>
except for <lower=0, upper=1>
or <lower=-1, upper=1>
.
In addition, a warning is generated when a parameter bound is found to have lower >= upper
.
For example, consider the following program.
parameters {
real<lower=0, upper=1> a;
real<lower=-1, upper=1> b;
real<lower=-2, upper=1012> c;
}model {
c ~ normal(b, a); }
Pedantic mode produces the following warning.
Warning:
Your Stan program has a parameter c with a lower and upper bound in its
declaration. These hard constraints are not recommended, for two reasons:
(a) Except when there are logical or physical constraints, it is very
unusual for you to be sure that a parameter will fall inside a specified
range, and (b) The infinite gradient induced by a hard constraint can cause
difficulties for Stan's sampling algorithm. As a consequence, we recommend
soft constraints rather than hard constraints; for example, instead of
constraining an elasticity parameter to fall between 0, and 1, leave it
unconstrained and give it a normal(0.5, 0.5) prior distribution.
34.3.10 Nonlinear transformations
When a parameter is transformed in a non-linear fashion, an adjustment must be applied to account for distortion caused by the transform. This is discussed in depth in the Changes of variables section.
This portion of pedantic mode tries to detect instances where such an adjustment would be necessary and remind the user.
For example, consider the following program.
parameters {
real y;
}model {
0,1);
log(y) ~ normal( }
Pedantic mode produces the following warning.
Warning:
Left-hand side of sampling statement (~) may contain a non-linear
transform of a parameter or local variable. If it does, you need
to include a target += statement with the log absolute determinant
of the Jacobian of the transform.
34.3.11 Pedantic mode limitations
Constant values are sometimes uncomputable
Pedantic mode attempts to evaluate expressions down to literal values so that they can be used to generate warnings. For example, in the code
normal(x, 1 - 2)
, the expression1 - 2
will be evaluated to-1
, which is not a valid variance argument so a warning is generated. However, this strategy is limited; it is often impossible to fully evaluate expressions in finite time.Container types
Currently, indexed variables are not handled intelligently, so they are treated as monolithic variables. Each analysis treats indexed variables conservatively (erring toward generating fewer warnings).
Data variables
The declaration information for
data
variables is currently not considered, so usingdata
as incompatible arguments to distributions may not generate the appropriate warnings.Control flow dependent on parameters in nested functions
If a parameter is passed as an argument to a user-defined function within another user-defined function, and then some control flow depends on that argument, the appropriate warning will not be thrown.