This document describes the process by which ergm and related packages selects the MCMC proposal for a particular analysis. Note that it is not intended to be a tutorial as much as a description of what inputs and outputs different parts of the system expect. Nor does it cover the C API.
There is a number of factors that can affect MCMC sampling, some of them historical and some of them new:
functions and other structures defined in an accessible namespace
ergm_proposal_table() a function that if called with no arguments returns a table of registered proposals and updates it otherwise. See ? ergm_proposal_table for documentation and the meaning of its columns. Of particular interest is its Constraints column, which encodes which constraints the proposal does (always) enforce and which it can enforce.InitErgmReference.<REFERENCE> a family of initializers for the reference distribution. For the purposes of the proposal selection, among its outputs should be $name specifying the name of the reference distribution.InitErgmConstraint.<CONSTRAINT> a family of initializers for constraints, weightings, and other high-level specifiers of the proposal distribution. Hard constraints, probabilistic weights, and hints all use this API. For the purposes of the proposal selection, its outputs include
$dependence (defaulting to TRUE) specifying whether the constraint is dyad-dependent;$priority (defaulting to Inf) specifying how important it is that the constraint is met (with Inf meaning that it must be met); and$implies/$impliedby specifying which other constraints this constraint enforces or is enforced by.arguments and settings passed to the call or as control parameters.
constraints= argument (top-level): A one-sided formula containing a +- or --separated list of constraints. + terms add additional constraints to the model whereas - constraints relax them. - constraints are primarily used internally observational process estimation and are not described in detail, except to note that 1) they must be dyad-independent and 2) they necessitate falling back to the RLEBDM sampling API.reference= argument (top-level): A one-sided formula specifying the ERGM reference distribution, usually as a name with parameters if appropriate.control$MCMC.prop= control parameter: A formula whose RHS containing +-separated “hints” to the sampler; an optional LHS may contain the proposal name directly.control$MCMC.prop.weights= control parameter: A string selecting proposal weighting (probably deprecated)control$MCMC.prop.args= control parameter: A list specifying information to be passed to the proposalMost of this is implemented in the ergm_proposal.formula() method:
InitErgmReference.<REFERENCE> is called with arguments of reference=’s LHS, obtaining the name of the reference.constraints= and MCMC.prop= are “merged”: the LHS of MCMC.prop= replaces that of constraints= and constraints=’s RHS is appended to that of MCMC.prop=’s.constraints= formula’s LHS, the corresponding InitErgmConstraint.<CONSTRAINT> function is called and their outputs are stored in a list of initialized constraints.ergm_proposal_table() are filtered by Clas, Reference, Weights (if MCMC.prop.weights differs from "default"), and Proposal (if the LHS of MCMC.prop is provided).priority=Inf, it is discarded.priority<Inf and that the proposal doesn’t and can’t enforce, its (innate, specified in the column of the ergm_proposal_table()) Priority value is penalised by the priority of that constraint.dependent==FALSE && priority==Inf (i.e., hard dyad-independent constraints) replaced by the catchall .dyads constraint, which all RLEBDM-aware proposals can handle.