Distributional refinements of randomized specifications #
A RandomizedSpec is a state-transition specification whose operations draw their outcome from a
distribution: law o is a stateful PMF handler. A client runs against it by
OracleComp.interpret, and RandomizedSpec.run is the joint distribution of its result and
final state. Its support is a relational StateTransitionSpec (RandomizedSpec.toSpec), and a
deterministic specification is a randomized one with point-mass outcomes
(StateTransitionSpec.toRandomized). An implementation that flips coins calls E.withCoins, the
interface E beside uniform sampling, whose clients are the ProbOracleComp E.Result programs.
A RandomizedRefinement D F extends a relational Refinement of the supports with one
distributional obligation. From a state satisfying the invariant, each admissible method's joint
distribution of answer and abstracted final state is the specified law (law). The relational
part then supplies the implementation invariant, the admissibility of lower calls and pathwise
amortized costs (Refinement.Amortized of toRefinement), and the law lifts to every adaptive
client (RandomizedRefinement.run_link). All probability is then done on the specification.
States, operations and answers live in Type, as for ProbOracleComp and
OracleComp.IdenticalUntilBad.
Failure events take one more step. If the real methods agree with exact ones until a bad lower
state (OracleComp.IdenticalUntilBad), any experiment on the real client accepts at most as often
as on the specification, plus the probability of the bad event
(RandomizedRefinement.bind_apply_le_of_identicalUntilBad). OracleComp.toOuterMeasure_bad_le
bounds that probability by per-call charges.
Expected costs go through charges as well. RandomizedSpec.expectedCost is the expected total
charge of a client. A RandomizedRefinement.ExpectedAmortized certificate bounds each method's
expected lower cost plus expected final potential by the upper charge plus the initial potential;
it telescopes along adaptive clients (ExpectedAmortized.client) and stacks across composition
(ExpectedAmortized.comp). When charges do not depend on the state, a query budget
(OracleComp.IsCostBounded) bounds the expected cost (expectedCost_le_of_isCostBounded).
Hops stack whether or not they flip coins. A deterministic refinement is a distributional one of
the point-mass laws (Refinement.toRandomized), and its pathwise amortized costs are expected
ones (Refinement.Amortized.toRandomized). Coins pass through a refinement unchanged
(RandomizedRefinement.withCoins), and two layers of coins merge into one
(RandomizedRefinement.mergeCoins). So a hop with coins of its own composes over a lower hop
with coins (RandomizedRefinement.compCoins), and expected potentials stack across it
(ExpectedAmortized.compCoins).
Main definitions #
RandomizedSpec,RandomizedSpec.run: randomized specifications and the law of a client run.RandomizedSpec.toSpec: the relational support.StateTransitionSpec.toRandomized: a deterministic specification as a randomized one.RandomizedSpec.withCoins: an interface together with private uniform coins.RandomizedSpec.obliviousClient: issue a fixed list of operations and record the transcript.RandomizedRefinement,RandomizedRefinement.ofLaw: distributional refinements, and the constructor that derives the relational step from the law.RandomizedRefinement.comp: composition.RandomizedRefinement.handler: the methods as a stateful handler on lower states.RandomizedSpec.expectedCost,RandomizedRefinement.ExpectedAmortized: expected charges and expected amortized cost refinements.RandomizedSpec.coinCharge: charges on an interface with coins.RandomizedRefinement.withCoins,RandomizedRefinement.mergeCoins,RandomizedRefinement.compCoins: coins through refinements, merged coin streams, and the composition of hops with coins.Refinement.toRandomized: a deterministic refinement as a distributional one.
Main results #
RandomizedSpec.mem_support_run_of_clientRun,RandomizedSpec.exists_clientRun_of_mem_support: the support of a run consists of the relational runs.StateTransitionSpec.run_toRandomized,StateTransitionSpec.toRandomized_step_iff,StateTransitionSpec.toRandomized_demonicValid_iff: a deterministic run is a point mass, and the support of a deterministic specification is itself, with the same admissible clients.RandomizedSpec.demonicValid_liftRight,RandomizedSpec.demonicValid_liftRight_iff,RandomizedSpec.demonicValid_sample_bind: coin calls are admissible, and programs overEkeep their admissibility.RandomizedSpec.expectedCost_bind,RandomizedSpec.expectedCost_le_of_isCostBounded,RandomizedSpec.isCostBounded_obliviousClient: expected charges of sequenced programs, and query budgets.RandomizedRefinement.run_link: the law of a linked client, read through the abstraction, is the law of the client on the specification.RandomizedRefinement.inv_of_mem_support_link: the invariant holds on every outcome.RandomizedRefinement.bind_apply_le_of_identicalUntilBad,RandomizedRefinement.abs_sub_le_of_identicalUntilBad: the identical-until-bad step.RandomizedRefinement.ExpectedAmortized.client,RandomizedRefinement.ExpectedAmortized.comp,RandomizedRefinement.ExpectedAmortized.of_isCostBounded: expected amortized costs.StateTransitionSpec.expectedCost_toRandomized,Refinement.Amortized.toRandomized: expected charges of deterministic runs, and pathwise amortized costs as expected ones.RandomizedRefinement.ExpectedAmortized.withCoins,RandomizedRefinement.expectedAmortized_mergeCoins,RandomizedRefinement.ExpectedAmortized.compCoins: expected amortized costs through coins.
References #
A randomized specification: from each state, an operation draws its answer and next state
from the distribution law o. Admissibility valid constrains only refinement certificates.
- State : Type
Mathematical states.
- Op : Type
Operations available to clients.
The answer type of each operation.
The distribution of the answer and the next state of each operation.
Preconditions under which an implementation must realize an operation.
Instances For
The support of a randomized specification as a relational specification: a step is permitted when the law gives it positive probability.
Instances For
The joint distribution of the result and the final state of a client run from s.
Instances For
A call followed by a continuation draws the call's outcome, then runs the continuation.
Running p >>= k runs p, then k at its result from the state it reached.
Mapping the result of a client maps the result of its run.
A single call draws its answer and next state from the law.
Every relational run of a client has positive probability.
On a demonically admissible client, every outcome of positive probability is a relational run.
The expected total charge of a client run from s, where a call o from state s costs
charge s o. Cslib.OracleComp.expectedCost is the stateless counterpart, for calls answered by
fixed distributions.
Instances For
The expected charge of a single call is its charge.
The expected charge of p >>= k is that of p plus the expected charge of the
continuation.
With charges independent of the state, a query budget bounds the expected charge.
Issue a fixed list of operations and return the transcript of operations and answers.
Instances For
The calls of an oblivious client cost the sum of the costs of its operations.
Private coins #
The interface E together with private uniform coins: a call .inl n is answered uniformly
from Fin (n + 1) and leaves the state unchanged, and a call .inr o is a call of E. Its clients
are the ProbOracleComp E.Result programs.
Instances For
A program over E alone runs as over E.
A closed sampler draws its value and leaves the state unchanged.
Admissibility over E is admissibility of the embedded program.
A program over E is admissible over E.withCoins exactly when it is admissible over E.
Coin calls are admissible, and leave the state unchanged.
A closed sampler followed by a continuation draws a value, then runs the continuation from the same state.
A single coin call is admissible.
A single admissible call of D, made over D.withCoins, is admissible.
A constant charge on coin calls and on calls of D is that constant on D.withCoins.
A program over D alone costs over D.withCoins what it costs over D.
Deterministic specifications #
A deterministic specification as a randomized one: each outcome is a point mass.
Instances For
Admissibility on a deterministic specification is admissibility on its support.
Admissibility of a deterministic history is admissibility on the support.
Over a deterministic specification with coins, a call steps the state and continues with its answer.
Over a deterministic specification with coins, an admissible call whose continuation is admissible from the next state is admissible.
The expected charge of a deterministic run is the total charge of its history.
Distributional refinements #
A randomized refinement of D by methods over F: a relational refinement of the supports
whose methods, from a state satisfying the invariant, realize the specified law through the
abstraction function.
- law {e : F.toSpec.State} (o : D.Op) : self.inv e → D.valid (self.abs e) o → PMF.map (fun (x : D.toSpec.Result o × F.State) => match x with | (a, e') => (a, self.abs e')) (F.run (self.methods o) e) = D.law o (self.abs e)
The answer and the abstracted final state of each admissible method follow the law.
Instances For
The constructor from admissibility, preservation of the invariant on outcomes of positive probability, and the law. The relational step follows from the law.
Instances For
The invariant holds after every outcome of positive probability of an admissible method.
An outcome of positive probability of an admissible method abstracts to a permitted step.
The distributional hop. The law of an admissible client linked through the methods, read
through the abstraction function, is the law of the client on the specification. This is
OracleComp.run_interpret_map_state_of_invariant for the methods' handler
(run_interpret_handler), with preconditions: the law need hold only for admissible operations,
and the client must be admissible.
The invariant holds on every outcome of positive probability of an admissible linked client.
Composition: the upper methods are linked through the lower ones, the invariants conjoin, and the abstraction functions compose.
Instances For
Identical until bad #
Interpreting a client through the methods' handler runs the linked client.
The identical-until-bad step. Let real methods agree with the methods of an exact randomized refinement until a bad lower state. Then an experiment continuing the real client run accepts at most as often as on the specification, plus the probability that the real run reaches a bad state.
The identical-until-bad step, two-sided. The acceptance probabilities of the real client and of the specification differ by at most the probability that the real run reaches a bad state.
Expected amortized costs #
Expected amortized cost refinement: the expected lower charges of every admissible method, plus the expected potential after it, are at most the upper charge plus the potential before it.
- step {e : F.toSpec.State} (o : D.Op) : M.inv e → D.valid (M.abs e) o → F.expectedCost lower (M.methods o) e + ∑' (x : D.toSpec.Result o × F.State), (F.run (M.methods o) e) x * potential x.2 ≤ ↑(upper (M.abs e) o) + potential e
The physicist's inequality in expectation, for one method.
Instances For
Expected potentials telescope along adaptive clients. The expected lower charges of an admissible linked client, plus the expected final potential, are at most the expected upper charges of the client on the specification plus the initial potential.
Expected potentials stack across composition. The composite is amortized in expectation with the upper potential, read through the lower abstraction, plus the lower potential.
With charges independent of the state, query budgets of the methods give an expected amortized certificate with zero potential.
Private coins through refinements #
The methods with private coins forwarded: a coin call .inl n is the same coin call, and a
call .inr o runs the method of o over F.
Instances For
Coins pass through refinements. A refinement of D by F refines D.withCoins by
F.withCoins, with the same invariant and abstraction: coin calls are forwarded unchanged, and
calls of D run their methods.
Instances For
The methods merging two layers of private coins: coin calls of either layer become coin
calls, and calls of G are forwarded.
Instances For
Two layers of private coins are one. Every call of G.withCoins.withCoins is one call
of G.withCoins with the same law, so the identity on states is a refinement.
Instances For
Coin-using hops compose. A refinement of D by F with coins, over a refinement of F by
G with coins, refines D by G with one stream of coins.
Instances For
Expected amortized costs pass through coins: coin calls cost the same on both sides and leave the potential unchanged.
Merging coin streams costs one call per call, with zero potential.
Expected potentials stack across coin-using hops.
Deterministic refinements #
Deterministic hops are distributional hops. A refinement of deterministic specifications refines their point-mass laws, with the same methods, invariant and abstraction.
Instances For
Pathwise amortized costs of a deterministic refinement are expected amortized costs of its distributional form.