The problem
The mathematics the core rests on, from quantities, their charts and their products, through operations and their derivatives of first and second order composed over programs, to queries, terms, importance weights, random keys and retirement.
The problem#
The core is the part of skoro that every later entry builds on: the quantities a model is made of, the operations that relate them, the derivatives of those operations, the log-density a model defines, and the changes a model goes through as it is built, branched and retired. It ships no distribution, but it must be exactly right about what a distribution, an estimator or a sampler will ask of it, because each of those will trust it without checking.
This document works out that mathematics, at the level of precision the implementation needs. Most of it is standard, and the standard parts are in the math notes it depends on: retractions, automatic differentiation over frames, derivatives in tangent charts and product manifolds. What is particular to skoro, and what this document settles, is how those pieces meet the charter: which quantities are differentiated and when, what order of derivative a computation needs from each step, what selection and discrete quantities do to derivatives, what a query does to a model’s density, how random keys make draws reproducible, and what retiring a quantity means.
Setting#
A model is a set of quantities and a set of terms. Each quantity takes values in its type: a manifold of dimension with a retraction, or a countable set. Each term is a real-valued function of some of the quantities, its log-density, and the model’s log-density is their sum (the measure theory underneath is in the appendix),
For a manifold-valued quantity, and are its retraction and inverse retraction (2), and derivatives are read in tangent charts (1). A quantity’s dimension is that of its tangent space; its storage size is the number of reals that represent a point, which may be larger (a rotation has dimension and is stored as or numbers). Every flat vector of derivative coordinates in this document is indexed by dimension, never by storage.
Computation is batched: a model is evaluated at points at once, one per row of a batch. Rows never interact: an evaluation at points is independent evaluations, and every derivative below is per row. Batching is therefore absent from the mathematics, and only the implementation needs to keep it straight.
A model is two graphs over the same objects, and the rest of this document uses both. Each answers different questions, and neither is ever called simply “the graph”. The running example is a vehicle at and then , which measures a landmark at once from each position, as and .
The compilation graph#
The compilation graph records how values are computed. Its nodes are the model’s values: its quantities, its constants, and its mapped values, the outputs of operations, among which are the terms’ log-densities. It has an edge from each input of an operation to the operation’s output, so a node with incoming edges is a mapped value, computed from the nodes those edges come from.
- It is acyclic, because a model is built forward: an operation is added only after its inputs.
- Its roots, the nodes with no incoming edge and so no ancestor, are the quantities and the constants. They are the inputs of the map that the model computes, and every mapped value is a function of the roots it is reached from.
- A quantity is a root even when it was drawn from a distribution whose parameters are mapped values. That dependence belongs to the probabilistic graph below, not to this one, which is why no derivative ever flows through a sampler.
- Quantity
- Constant
- Mapped value
- A term's log-density
- input of an operation
Evaluating a model compiles a program from the compilation graph: the subgraph of the nodes from which a requested target is reached, its operations taken in a topological order. That subgraph is the program’s computation graph, and its roots are the roots of the compilation graph that the targets reach.
The probabilistic graph#
The probabilistic graph records what depends on what in distribution. Its nodes are the model’s quantities and its terms. It has an edge from each quantity a term is conditioned on to the term, and an edge from each term to the quantity it scores, if any.
- It is bipartite: every edge joins a quantity and a term.
- Each quantity is scored by at most one term: the term of the distribution it was drawn from. A term that scores nothing is a likelihood factor over the quantities it is conditioned on: in Bayesian terms, the likelihood of data that is not a quantity of the model, such as the measurements a retirement conditioned on. A term that scores an observed quantity is a likelihood too, but only in the queries that observe it; a likelihood factor is one in every query.
- It is acyclic, because a term is conditioned only on quantities that existed before the quantity it scores. A topological order of it is therefore an ancestral order, in which each quantity comes after everything its distribution is conditioned on.
- Its edges are read off the compilation graph rather than declared: a term is conditioned on the quantities among the roots its log-density is reached from, other than the one it scores.
- Quantity
- Term
- conditions a term
- scores a quantity
Quantities#
Euclidean quantities. The core’s flat types are the real line , vectors and matrices , with and . A matrix is flattened column by column into for its tangent coordinates, so its dimension equals its storage size. The dimensions , are fixed for each quantity when it is created, and every operation checks them then.
Positive quantities. Scales, rates and variances live on the positive orthant , with the retraction of the example in retractions, elementwise:
A tangent coordinate is a relative change, and a point is stored as its values, so its dimension equals its storage size. The positive orthant is not flat in the sense of the notes, since is not addition, but it is flat in disguise: , so the logarithm is one chart of the whole space in which every retraction is a translation. Three things follow. The retraction is defined for every and never leaves the space. The identities and both hold exactly. And the chart Hessian equals the Hessian of the pull-back everywhere, not only at stationary points: in Proposition 5, , whose derivative does not move, so the correction vanishes. What is not trivial is reading a positive quantity as a real number, through the inclusion : its derivative in charts is , which moves with the point.
Discrete quantities. The core’s discrete types are the finite sets , with , and the integers . A discrete quantity has no tangent space, no retraction and no dimension, and it is never a coordinate of a derivative. Its values are written . A density over a discrete quantity is a probability mass, a density with respect to the counting measure.
Products. A product of continuous types is a continuous type: a quantity of type is one point , stored as its factors’ storage concatenated, with the stacked tangent space (1) and the factor-wise retraction of Proposition 2. The core has products of continuous types only. A quantity with a continuous part and a discrete part is two quantities, as the charter has it, and a joint density over several discrete quantities needs no product, since a term may be conditioned on any number of quantities.
A product’s factors may be of any continuous type, including products, and of dimensions known only at run time. That is what makes a product the natural type of a marginal over a Markov blanket, whose members are only known when a quantity is retired (Retirement).
Operations#
An operation is a smooth map
from continuous inputs and discrete inputs to an output , smooth in the continuous inputs for each value of the discrete ones. In the compilation graph it is a mapped node with an incoming edge from each input. Its partial derivatives are taken in tangent charts, and it may provide four maps, each over a frame of directions (automatic differentiation over frames):
| map | given | returns |
|---|---|---|
| forward | the inputs | |
| tangent | a frame per continuous input | |
| cotangent | a frame at the output | per continuous input |
| second order | velocities , and one cotangent | per input |
The second-order map takes a velocity frame of several columns, one Hessian direction each, and a single cotangent column. Its definition in charts is the one under which a forward-over-reverse pass computes the chart Hessian (4), by Proposition 6.
Discrete inputs carry no derivatives, and a discrete output carries none either. A map that turns a discrete input into a continuous output (an embedding, such as an integer read as a real) has no partial derivative in it. A map that turns a continuous input into a discrete output (a discretization, such as the indicator ) passes no cotangent back. For a step function that is the true derivative everywhere but at its steps, and the core makes no attempt to do better: a model that needs a derivative across a discretization needs a relaxation, which is a modelling choice, not the core’s.
Two gates#
A pass runs over a program’s computation graph, whose roots include the quantities it differentiates with respect to. Within a pass, an operation’s continuous inputs differ in two ways that the implementation must keep apart:
- an input is differentiable if it is reached from a root the pass differentiates with respect to, which decides whether cotangents (, and in a Hessian pass ) are pulled back into it along the backpropagation graph;
- an input carries a velocity if it is reached from a root seeded with a velocity in this pass, which decides whether its velocity enters .
The second implies the first, and not conversely: a Hessian pass is often seeded at one quantity while all of them are differentiated. An operation’s is absent whenever is not needed, and a missing velocity counts as zero.
Order#
Every operation states its order : if it provides only the forward map, if it also provides the tangent and cotangent maps, if it also provides the second-order map. Most primitives have order . An operation that runs burn’s automatic differentiation inside, such as a neural network, has order ; one whose derivative does not exist or was not written has order . What a pass needs of a step depends on where the step sits in the program’s computation graph.
Fix a pass over a program: the roots it differentiates with respect to, the roots seeded with velocities (for a Hessian pass), and the targets . A step with map is on the pass when, in the program’s computation graph, its output is continuous and reaches a target in , and one of its continuous inputs is reached from a root in . The order the pass requires of step is
The pass is admissible when for every step .
A pass that is not admissible is refused before it runs, naming a step with . This refines the charter’s “least order over the program’s steps” in two ways that matter in practice. A step that no differentiated root reaches, or that reaches no target, needs nothing, so a model may contain a first-order neural network and still be differentiated twice with respect to quantities that do not feed it. And a step that only pulls back cotangents in a Hessian pass, because no seeded velocity reaches it, needs only first order: its terms are zero by (4).
Selection#
Selection chooses one of several continuous values by a discrete index:
All the and are of one type. For each the map is a projection, so its derivatives in charts are as simple as derivatives get: since , the chart at is the chart at , and
The cotangent at goes to the selected value and nowhere else, and the index receives nothing. Mixtures, switching models and data association are built on selection: a mixture whose component is a discrete quantity reads that component’s parameters through selection, and a measurement associated by a discrete quantity selects the target it came from. The derivative with respect to the values, at a fixed index, is exactly what a gradient-based algorithm conditioned on the discrete quantities needs.
The primitives#
The core ships all of the primitive operations below, with the derivative maps they carry; those on Euclidean quantities first. In the table, is the elementwise product, the velocity of an input in a Hessian pass (or its tangent, in the tangent map), and the cotangent at the output. Each frame is handled column by column, so one column is shown.
| operation | tangent | cotangent per input | second order per input |
|---|---|---|---|
| , | |||
| (elementwise) | |||
| (elementwise) | |||
| slice, concatenate, transpose | the same map | its adjoint | |
| select | (5) | to the selected value |
The operations on positive quantities read their tangents and cotangents in the charts (2), that is, in logarithmic coordinates, where all but the inclusion are linear. Here and are positive, is Euclidean, and the products, quotients and powers are elementwise.
| operation | from, to | tangent | cotangent per input | second order per input |
|---|---|---|---|---|
| as a real | ||||
The exponential and logarithm here are not the rows of the first table: those map to , read in the flat charts, where their derivatives are and ; these change type, and in the charts of the positive side their derivatives are identities. Both are kept, because a model may want either. The retraction (2) is the composite of the second and fourth rows, and its inverse of the third and a Euclidean subtraction, so every derivative of both, of either order, is an identity or zero.
Every row is checked the same way: the tangent map is the derivative of the forward map, the cotangent map its transpose, and the second-order map the derivative of the cotangent map along the velocities, holding fixed. The bilinear operations (, , ) are the only ones whose second-order maps mix inputs: the pull-back into one input involves the other, so the other’s velocity appears. The linear ones have none. The discrete operations the core needs (integer arithmetic and comparison) and the embedding of an integer as a real carry no derivatives, by the conventions of Operations.
Programs, composites and passes#
A model is evaluated by compiling a program from the compilation graph, as in The compilation graph. Four passes run over a compiled program: the forward pass, the tangent pass (2) along the edges of its computation graph, the cotangent pass (3) along the edges of its backpropagation graph, and the Hessian pass (4), which runs both. Derivatives are collected at the program’s roots only, which are the leaves of its backpropagation graph, and Queries says which roots those are.
A composite operation is a named subgraph of the compilation graph, such as the retraction of a product, or (in later entries) a distribution’s log-density: a set of operations with designated inputs and one output, stored under one name. Its derivative maps are defined as the composition of its parts’, so expanding a composite into its parts at compilation changes no value that any pass computes, and its order is that of its parts under Definition 4. A hand-written fused form of a composite, introduced for speed or for numerical care, is a different operation with the same mathematics, and it is correct only if every pass over it agrees with every pass over the composite, to within rounding.
The product retraction is the composite the charter’s acceptance test is about.
Let a product’s retraction be built as the composite of slicing the point and the tangent into blocks, applying each factor’s retraction to its blocks, and concatenating the results. Then every pass over a program containing it (values, tangent frames, cotangent frames, and Hessian products) computes the same values as the factor-wise computation, block by block.
Slicing and concatenation are linear, so their tangent maps are themselves, their cotangent maps are their adjoints (scattering into a zero block and gathering a block), and their second-order maps are zero. In the tangent pass, slicing hands each factor’s retraction exactly its blocks of the frames, and concatenation stacks what they return. In the cotangent and Hessian passes, the concatenation’s adjoint hands each factor exactly its blocks of and , the factors pull them back, and the slicing’s adjoint places each result in its own block, adding only zeros. By (4), with the linear steps’ zero, the product’s is the factors’ s, stacked. So every pass computes the block-diagonal assembly of the factors’ passes, which is the derivative structure of (3).
∎The proof introduces no arithmetic beyond additions of zero, so a test may hold the agreement to a tolerance of a few units in the last place.
The acceptance test#
The charter accepts its position on products on one condition: that the retraction of a runtime product, and its first and second derivatives, agree with the factor-wise computation. On the core’s own types that is a weak test at second order. In the charts of every one of them a retraction is a translation, so every second-order map along it is zero, and the second derivatives under test are zeros on both sides. The test is therefore run on a product that includes a curved factor, and composed with a function whose second derivative does not vanish.
A test-only sphere. The core’s tests carry a private type, never shipped: the unit sphere , of dimension and storage size . Its tangent plane at is , identified with by a matrix whose two orthonormal columns span it. No such is smooth on the whole sphere (a smooth field of tangent bases on would give a nowhere-vanishing tangent vector field, which the hairy ball theorem rules out), so the identification is smooth on an open part of the sphere, and the tests stay inside it. Its retraction projects back onto the sphere:
The inverse follows from : the point is with the norm, so and . The derivative of the retraction at is , whose coordinates are , so it is a retraction. Unlike the core’s types, the sphere is curved: its tangent charts do not commute, the correction term of Proposition 5 is not zero away from stationary points, and the retraction’s second-order maps are not zero. Its retraction is a composite of three private primitives with hand-written derivatives in charts: the inclusion , the map , and the normalization from onto the sphere.
What it compares. The test builds a runtime product of two Euclidean factors, a real line, a positive factor and the sphere, and a nonlinear scalar function on it that reads the positive factor and the sphere as real numbers, through their inclusions. It checks, at points away from the singular set of :
- that every pass over the product’s retraction, values, tangent frames, cotangent frames and Hessian products, agrees with the factor-wise computation, block by block, as Proposition 6 says it must;
- that the chart gradient and the chart Hessian products of through the product’s retraction, computed by the passes, agree with the factor-wise assembly of (3), and with finite differences of their definitions (3) and (4);
- that on the sphere’s block, away from a stationary point, the chart Hessian differs from the Hessian of the pull-back by the correction term, and on every other block it does not.
The private primitives’ own derivatives are checked the same way first, against finite differences of (1), so that a failure of the acceptance test points at the composition rather than at a primitive.
Queries#
The charter puts conditioning in the query: the model holds the joint density (1), and each question asked of it says which quantities are fixed. A query partitions the quantities its targets reach in the compilation graph into
- the observed quantities , fixed at values the query gives;
- the free continuous quantities , the variables of the query;
- the free discrete quantities , which a generation draws, and whose values any other query gives and holds fixed.
The query’s log-density is then a function of alone,
which is, up to the constant , the log-density of the conditional distribution of given the rest. One model answers many queries: with the measurements observed it is a posterior; with nothing observed, a prior to simulate from; with the states observed, a likelihood of measurements.
Roots. The roots of a query’s program, the roots of its computation graph, are the quantities and constants its targets reach. Of these, the free continuous quantities are the ones every pass differentiates with respect to, in their tangent charts; the observed and discrete quantities and the constants are fixed inputs. A quantity’s value is an input of the query even when the quantity was drawn from a distribution whose parameters depend on other quantities, since it is a root of the compilation graph: counts ’s appearances in the terms, never its role in generating its children.
Folding. A mapped value whose inputs are all fixed is itself fixed, and need not be computed on every evaluation: it can be computed once and put in place of the subgraph that computes it, as a new root. Nothing a pass computes changes, since no derivative flows into a fixed value. A value is fixed at one of two levels, and is folded at that level.
- In the model. A value reached only from constants is the same in every query, snapshot and branch, so it is folded once, when it is added to the compilation graph, and the model keeps the result, in double precision on the host like every value it stores. A query casts it to its own precision like any other constant. Conditioning in the query does not prevent this: a constant is not a quantity, so no query can observe or free it.
- In a compiled query. A value reached from observed quantities, and from constants, is fixed only for the queries that observe those quantities, so it is folded when such a query is compiled, and reused by every evaluation of the compiled program.
A value reached from a free quantity is not folded. The difference shows in a Gaussian term written with a covariance factor , whose log-density reads its inverse and the logarithms of its diagonal (a later entry decides how the Gaussian takes its covariance). If is a constant, both are folded once in the model; if it is an observed quantity, once per compiled query; if it is free, they are computed on every evaluation, together with their derivatives with respect to .
Discrete quantities in a query. The gradient of (8) at fixed is the gradient of the conditional density of given . An algorithm that targets the distribution of alone, with unobserved, needs summed or sampled out, which a gradient cannot do; that is why the charter has a gradient-based algorithm refuse a query with a free discrete quantity, rather than silently condition on the value it was given.
Flattened coordinates. An estimator works with vectors, not with quantities. Ordered as the estimator chooses, the free quantities are one point of the product manifold , a tangent of which is a vector , , stacked by (1). An estimator’s step is that product’s retraction,
and a Jacobian, gradient or Hessian over is the block matrix of (3). So the layout an estimator uses and a product quantity type are the same mathematical object, and the core should build them from one construction.
Terms and the importance weight#
A term is a node of the probabilistic graph. Its log-density is a node of the compilation graph, computed from the quantities it is reached from there. Following the charter, a term records the quantity it scores, , if any, and the quantities it is conditioned on, , so that reads as . The quantities a term involves, , its neighbours in the probabilistic graph, determine every structural question the core answers: which terms touch a quantity, what a quantity’s Markov blanket is, and what retiring it disturbs. They are only right if they contain every quantity depends on, so the core reads off the compilation graph, as the quantities among the roots is reached from, rather than trusting a declaration; is then without . In the example, is reached from , and , and the term scores , so it is conditioned on and .
The generative reading. A distribution may provide a sampler for the quantity it scores, which draws given , with a log-density of its own; an exact sampler has (charter, position 9). A query generates its free quantities, continuous and discrete, ancestrally: each from the sampler of the term that scores it, in a topological order of the probabilistic graph. In this section, stands for all of them. Generation is possible exactly when every free quantity is scored by a term with a sampler; it is refused otherwise, naming a quantity that is not. The importance weight of a generated point is
which is the charter’s (1), with the observed quantities’ terms and the likelihood factors, the likelihoods of this query, contributing alone, and each term whose sampler is exact cancelling.
Let a query leave the quantities free and fix , and suppose that every free quantity is scored by exactly one term, whose sampler has density with wherever , each pair with respect to the same base measure. If is drawn ancestrally from the samplers, then for every integrable ,
Ancestral generation draws with density with respect to the product of the base measures, since each quantity is drawn given quantities drawn or fixed before it. Then wherever , which covers the support of by the positivity condition, and .
∎Two conditions in the statement are the core’s to check or to state. The base measures must match. In the core, a continuous quantity’s density is with respect to Lebesgue measure on the space its values lie in, or the open subset of it, and a discrete quantity’s with respect to counting measure, so this holds as long as every distribution keeps to that convention. The one place it is easy to break is a density written in the logarithmic chart of a positive quantity, such as a log-normal written as a normal in : with respect to Lebesgue measure on , it carries the Jacobian of the chart,
Densities on manifolds without such a chart will need a base measure of their own when the first of them arrives. Positivity is the distribution’s responsibility, and the core cannot check it.
Random keys#
Every draw comes from a key (charter, position 10). Mathematically a key is an element of a finite set , with two deterministic maps: , and , which folds in one address segment from the set of names and integers. The key of the quantity at address in a run with key is
and its sampler turns into the uniform variates it consumes. Because depends on and alone, a quantity’s draw does not depend on the order in which the model was built, on what was retired before it, or on which branch holds it, and a namespace’s keys share the prefix of folds that the namespace’s own address determines.
The independence of draws rests on an idealization: that and behave as a pseudorandom function, so that distinct addresses yield keys
indistinguishable from independent uniform ones. Two things the core must ensure for that to mean
anything. Distinct addresses must give distinct inputs: each segment’s encoding must be injective
and tagged by its kind, so that the name "3" and the integer differ, and folding segment by
segment, rather than hashing a concatenated string, rules out collisions such as ab/c against a/bc. And each batch row of a run must have its own run key, split from the run’s, so that rows
are independent.
Because the uniform variates are drawn on the host from the key and then converted to the precision a query computes in, one key gives the same draws at single and double precision, up to the rounding of the conversion.
Retirement#
Retiring is the one change that shrinks a model: the quantities under a namespace are removed, and what they said about the rest is kept. Retirement is read on the probabilistic graph. Let be the quantities to retire, the terms joined to any of them (), and
their Markov blanket: the other quantities joined to those terms. In the example, retiring the first tick, , touches the terms , and , and its blanket is .
Retirement must condition as well as marginalize. The retired namespace of a tick holds that tick’s measurements as well as its states, and integrating the measurements out of the joint would discard exactly the information a sliding window keeps them for. So the quantities of split into those fixed at given values, (usually the measurements, with the values the estimator observed), and those integrated out, . Since conditioning belongs to the query, the values of are given to the retirement itself, and once retired they become part of the model: what remains is the joint of the remaining quantities given those values.
Let be the quantities to retire, of which are fixed at given values and are integrated out, let be the terms joined to a quantity of in the probabilistic graph, and let be the other quantities joined to those terms. Replace the terms by the single term
Then, as a function of every quantity outside , the new model’s density equals the old model’s density with integrated out and fixed at its values.
Split (1) into the terms of , which involve only and , and the rest, which involve no quantity of . Fixing and integrating over , the second group comes out of the integral as a constant factor, by Tonelli’s theorem for the non-negative integrand, and what remains of the first group is .
∎The replacement must be computed from the terms alone. Computing the marginal of the whole model on instead would fold in the terms outside , which the model still holds, and count them twice. The integral defining rarely has a closed form. It has one for linear-Gaussian terms, where retiring the oldest state of a chain is the update-and-predict step of a Kalman filter; otherwise it is approximated, by a Laplace approximation at the current estimate in the archive’s sliding windows. Either way, computing it needs the distributions and the linear algebra of later entries; what the core needs is the structure: , , , the removal, and a place for the replacement, a likelihood factor over whose type, when it is one density over the blanket’s tangent coordinates jointly, is the product of the blanket’s types.
Two consequences for the rest of the model:
- Mapped values. In the compilation graph, a mapped value under the retired namespace that a remaining node is reached from, and that is reached only from remaining roots, is not a function of and must not be removed with it. One reached from can only reach terms in , which are replaced, and other mapped values reached from , which go with it.
- Generation after retirement. A blanket quantity whose scoring term was in ( in the example, whose transition was conditioned on ) is scored by no term afterwards, only joined to the replacement. Unless the replacement is written in a generative form, as a term scoring that quantity with a sampler, generation from the new model is refused for it, by structure.
In skoro’s terms#
- Quantities are Euclidean (real, vector, matrix), positive (, with the retraction (2)), and discrete (categorical, boolean, integer), and products of continuous quantities. Dimensions are fixed when a quantity is created, and every derivative coordinate is indexed by tangent dimension.
- The compilation graph holds values and operations, and programs are compiled from it; the probabilistic graph holds quantities and terms, and is read off the compilation graph and each term’s scored quantity.
- Operations are maps (3) with up to four derivative maps over frames, each with an order. The core’s primitives are those of The primitives, and every other operation, the product’s retraction included, is a composite of them.
- Folding replaces a value reached only from fixed inputs with a root: in the model when they are constants, in a compiled query when they include observed quantities.
- Passes are the forward, tangent, cotangent and Hessian passes over a compiled program, differentiating with respect to a query’s free continuous quantities in their charts, refused before running when not admissible by Definition 4.
- The density is the sum of terms (1). A query fixes the observed quantities and the discrete ones, and its density is (8). Generation is ancestral from samplers, and its weight is (10).
- Random keys are derived from addresses by (13).
- Retirement removes a namespace’s quantities , conditioning on the given values of and integrating out , and replaces the terms with one term over the blanket (14).
Appendix: the probability space of a model#
A skoro model is a model built forward in the sense of models built forward, for the measure theorist, and every object in this document has a place in that note’s measure theory.
- Quantities are the coordinates. Each quantity lives in a space with a reference measure: Lebesgue measure on and and on the open subset , counting measure on and on , and product measures on products. The probability space can be taken to be the product of the quantities’ spaces, with the quantities as its coordinates, and the probabilistic graph’s ancestral order as the order in which they were built.
- Terms are conditional densities. A term that scores a quantity has, as its , that quantity’s conditional density given those it is conditioned on, so (1) is the logarithm of the joint density of Proposition 5. A likelihood factor is the change of measure of Proposition 10.
- Mapped values are functions of the quantities, and by Lemma 7 they are all the random variables a model can express. Their laws are image measures, with no density in general, which is why no term scores one.
- A query conditions by dividing densities. Its log-density (8) is that of the regular conditional distribution of Proposition 9, up to the constant , which is why a query may drop it.
- Every number an algorithm estimates is an integral against the joint density, by Corollary 8: an expectation, a marginal, the evidence . Generation draws from the conditional densities in the order the model was built, which is Ionescu-Tulcea’s construction, and importance weighting (10) estimates such an integral from those draws.
- Retirement integrates and conditions. Proposition 15 integrates the retired free quantities out of the terms that touch them and conditions on the retired observed ones, which is the same marginalization and the same division of densities, carried out once and kept.
The test-only sphere has no reference measure in this sense, since it is not an open subset of a coordinate space; it carries no density in the core’s tests. Manifold-valued quantities beyond the positive orthant will need reference measures of their own (surface measure on a sphere, Haar measure on the rotations) when they arrive.