Trim AlgorithmsInterfaceExtensions to a minimal NestedAlgorithm

[mtfishman]

Trim AlgorithmsInterfaceExtensions to just NestedAlgorithm — abstract type + initialize_subsolve + finalize_substate! + AI.step!. Everything else (Problem/Algorithm/State abstract types, DefaultState, DefaultNestedAlgorithm, FlattenedAlgorithm, AlgorithmIterator, NonIterativeAlgorithm, …) is removed, along with the placeholder src/sweeping/ and its tests.

The belief-propagation code is refactored into three Problem / Algorithm / State triples — outer BeliefPropagation*, middle BeliefPropagationSweep*, inner MessageUpdate* — each subtyping AI.* directly and modeled on the WIP gate-apply code (#114).

[codecov]

Codecov Report

❌ Patch coverage is 77.69231% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.23%. Comparing base (bd91366) to head (3c9c2d8).

Files with missing lines	Patch %	Lines
...terfaceExtensions/AlgorithmsInterfaceExtensions.jl	66.07%	19 Missing ⚠️
src/beliefpropagation/beliefpropagation.jl	86.48%	10 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #115      +/-   ##
==========================================
- Coverage   75.81%   73.23%   -2.58%     
==========================================
  Files          23       21       -2     
  Lines         980      923      -57     
==========================================
- Hits          743      676      -67     
- Misses        237      247      +10     

Flag	Coverage Δ
docs	0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jack-dunham]

I was anticipating this would also take in the edge order to be updated, as that defines the sweep problem (we wish to sweep over these edges of the factor graph). Something like:

# Problem of solving this sequence of region sweeps on this factor graph
struct BeliefPropagationSweepProblem{Factors, Regions} <: AI.Problem
    factors::Factors
    regions::Regions
end

[mtfishman]

Agreed, good point.

[jack-dunham]

One can then directly use his problem:

struct BeliefPropagationSweepProblem{Factors, Edges} <: AI.Problem
    factors::Factors
    edges::Edges
end

to implement tree BP, or in combination with a message update algorithm that gauges to implement a gauge walk. e.g:

struct TreeBeliefPropagationProblem{Factors, V} <: AI.Problem
    factors::Factors
    root::V
end
function solve!(prob::TreeBeliefPropagationProblem, alg::TreeBeliefPropagationAlgorithm, state)
    edges = ... # use `alg` and `prob.root` to make edge sequence
    sweep = BeliefPropagationSweepProblem(prob.factors, edges)
    solve!(sweep, ...)
end

[jack-dunham]

Again, I envisioned:

# Update the message associated with `region` of the factor graph defined by `factors`.
struct MessageUpdateProblem{Factors, Region} <: AI.Problem
    factors::Factors
    region::Region
end

[mtfishman]

Yeah, this was the part of the design I was least sure about, i.e. which information should be the problem, algorithm, and state for the message update. I think that makes sense to put which edge is being updated in the problem. Is there a reason to call it "region" instead of "edge"? I would find "edge" easier to understand.

[jack-dunham]

Edge is fine, I was just trying to be generic.

[jack-dunham]

Does this need to be a subtype of AI.State? Can one not just use the MessageCache directly? Is it because we need to dispatch on solve_loop! now instead of solve!?

[mtfishman]

Yeah, it is because we are using parts of the AlgorithmsInterface like solve!, intialize_state, etc. I agree that would be less code/boilerplate, for this layer it is a lot of boilerplate for something pretty simple, we could definitely debate about which level we should overload. I found this choice to be conceptually a little bit simpler.

[jack-dunham]

I was thinking BeliefPropagationSweepAlgorithm could host an ordered mapping from an edge to a message update algorithm. Then one does:

function initialize_subsolve!(problem::BeliefPropagationProblem, algorithm::BeliefPropagationAlgorithm, state::BeliefPropagationState)
    subalgorithm = algorithm.sweeps[state.iteration] # a BeliefPropagationSweepAlgorithm
    edges = keys(subalgorithm.updates)
    subproblem = BeliefPropagationSweepProblem(problem.factors, edges)
    substate = initialize_state(subproblem, subalgorithm; iterate = state.iterate)
    return subproblem, subalgorithm, substate
end

and also (property/variable names for illustration only)

function initialize_subsolve!(problem::BeliefPropagationSweepProblem, algorithm::BeliefPropagationSweepAlgorithm, state::BeliefPropagationSweepState)
    edge = problem.edges[state.iteration]
    subalgorithm = algorithm.updates[edge]
    subproblem = MessageUpdateProblem(problem.factors, edge)
    substate = initialize_state(subproblem, subalgorithm; iterate = state.iterate)
    return subproblem, subalgorithm, substate
end

[mtfishman]

I was thinking BeliefPropagationSweepAlgorithm could host an ordered mapping from an edge to a message update algorithm.

Interesting idea, I'll try to incorporate that into the PR.