Edit on GitHub

Acceptance Functions

Acceptance functions are user-defined functions passed to recom_chain/flip_chain that are used to evaluate a proposal for the next state in a chain and generate a probability for "accepting" the new plan. If the plan is rejected, then the step in the Markov chain is considered to be a "self-loop." Note that acceptance functions are conceptually different from constraints, which are hard, deterministic requirements on every plan in a chain. If a plan is generated that does not satisfy a constraint, then new plans are generated until the constraint is satisfied, at which point the chain makes a step to the constraint-satisfying plan. Contrast this to acceptance functions, which generate probabilities for accepting a plan, and when a plan is not accepted, produce a self-loop in the chain.

Practically, acceptance functions are expected to accept a Partition object and return a probability between 0 and 1. The reason for this is that acceptance functions are really most useful in cases like the Metropolis-Hasting algorithm and "burning in". If, for some reason, you need a deterministic acceptance function, you can simply have it return 0 or 1.

The following is a sample acceptance function included in the GerryChain library:

API

GerryChain.satisfies_acceptance_fn — Method
satisfies_acceptance_fn(partition::Partition,
                        acceptance_fn::Function)::Bool

Determines whether a partition should be accepted, according to the user-specified acceptance function. Acceptance function must return a valid probability in [0, 1], and satisfies_acceptance_fn will use this probability to determine whether the partition should be accepted.

Arguments:

  • partition: Partition. Should have a valid "parent" field so the acceptance function can compare the new partition to the previous partition, if necessary.
  • acceptance_fn: A user-specified function that should take partition as an argument and return a probability in the range [0, 1].
source