TuringLang / TuringLang/DynamicPPL.jl

Pass stochastic-state schemas through the unified evaluation context

Open
#1,480 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Julia
Stars
286
Forks
41
Avg merge
1d 11h
Merged PRs (30d)
34

Description

Extend DynamicPPL#1469 with an automatically derived AbstractPPL of schema in the single Context. This builds on JuliaBUGS’s schema system while retaining ordinary model syntax, without the special argument proposed in #965.

Proposed API sketch:

@model function model(y)
    k ~ DiscreteUniform(1, 3)
    theta ~ product_distribution([Normal() for _ in 1:k])
    y ~ Normal(sum(theta), 1)
end

m = model(0.3)
s = (; k=2, theta=[0.2, -0.1])

context = Context(
    rng,
    InitFromParams(VarNamedTuple(s), nothing),
    UnlinkAll();
    schema=of(s),
)

retval, vi = evaluate!!(m, context, VarInfo(accumulators))

Here VarInfo is #1469’s output-only accumulator collection; accumulators selects density and active-layout outputs.

Density evaluation consumes supplied values without implicit latent sampling. Each tilde operation validates compatibility with the supplied schema and distribution. Preparation discovers an initial layout through execution; dimension-changing kernels construct compatible proposals. Schemas support preallocation and storage reuse, accompanied by active-site and transformation metadata.

Schema validation would be optional, with three supported workflows:

  • Declared: supply a schema explicitly using the existing @of syntax.
  • Discover and freeze: evaluate with NoSchema(), collect the realised schema, then pass it into subsequent evaluations for validation.
  • Discover per simulation: evaluate each simulation with NoSchema() and collect its realised schema; use that schema when scoring the resulting state.

NoSchema() imposes no additional schema constraints, preserving existing behaviour. Schema collection is an independent output operation, and existing initialisation, transformation, and sampler checks remain in force.

Generative evaluation must distinguish prescribed layouts from layouts being constructed. PG reference replay preserves retained active variables and native shapes, while fresh particles may generate different layouts. Conditioned values remain unchanged. Evaluation records realised layouts in output accumulators rather than mutating the input schema. Reuse requires explicit output-to-input conversion.

The Gibbs rewrite reconstructs active state after component updates. Returning validated metadata from accepted-state evaluations could avoid that reconstruction where an evaluation already occurs. Turing#2891 illustrates why container shapes alone are insufficient.

Generative execution also supports SMC, initialisation, and prior-proposal MH. Kernels remain responsible for proposal-density corrections, valid dimension-changing transitions, and linking corrections when targeting linked coordinates.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with DynamicPPL#1469 and the proposed Context, evaluate!!, VarInfo, NoSchema(), and @of entry points to understand the existing evaluation flow. Review src/mcmc/mh.jl and the linked Gibbs rewrite for related generative and accepted-state behavior; done means unified schema handling, validation, layout metadata, and compatible workflows across the listed evaluation paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
backend, machine-learning
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.