Skip to content

Adopt ReversePropagation 0.8 SSAFunction + RuntimeGeneratedFunctions API#228

Open
dpsanders wants to merge 3 commits intomasterfrom
use-rp-ssa
Open

Adopt ReversePropagation 0.8 SSAFunction + RuntimeGeneratedFunctions API#228
dpsanders wants to merge 3 commits intomasterfrom
use-rp-ssa

Conversation

@dpsanders
Copy link
Copy Markdown
Member

Summary

  • Contractor now lowers its expression to a ReversePropagation.SSAFunction once via cse_equations and passes that SSA into forward_backward_contractor(ssa, vars); the SSA is stored on the contractor so it can be reused across multiple contractors/constraints over the same expression.
  • Separator(ex, vars, constraint) shares that SSA between its forward evaluator and its HC4Revise contractor, so the symbolic CSE pass runs once per separator instead of twice.
  • make_function switches from eval to @RuntimeGeneratedFunction, matching RP's own shift — generated functions can now be built and invoked within the same dynamic extent without Julia world-age errors, with much faster build time.
  • Bumps [compat] ReversePropagation = "0.8", adds RuntimeGeneratedFunctions = "0.5" as a direct dep, and bumps package version to 0.16.0.
  • Drive-by fix to a garbled .gitignore entry.

Blocker

This PR depends on ReversePropagation 0.8.0, which is not registered yet — it lands with the SSAFunction / RGF refactor currently split across the open PRs in that repo. Until it is released, CI here will fail to resolve; local reviewers can ]dev the local RP checkout (as this was developed and tested against).

Test plan

  • Pkg.test() passes locally (Contractors 4/4, Separators 4/4, pave 7/7, Paving a 3D torus 1/1) against a dev'd RP 0.8.0
  • CI green once RP 0.8.0 is registered

🤖 Generated with Claude Code

dpsanders and others added 3 commits April 20, 2026 09:52
Contractor now lowers its expression to an SSAFunction once via
cse_equations and passes that SSA to forward_backward_contractor. The
SSA is stored on the contractor so it can be reused across multiple
constraints over the same expression. Separator shares the SSA between
its forward evaluator and its HC4Revise contractor, so each constructor
does the symbolic CSE pass only once.

make_function switches from eval to @RuntimeGeneratedFunction, matching
RP's own shift: generated functions can now be built and invoked within
the same dynamic extent without hitting Julia world-age errors, with
much faster build time.

Bumps compat to ReversePropagation = "0.8" and adds
RuntimeGeneratedFunctions as a direct dep. ICP package version bumped
to 0.16.0. Drive-by fix to a garbled .gitignore entry.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
IntervalArithmetic v1 taints any interval that touches a plain (non-
ExactReal) Real with the "not guaranteed" (NG) flag. ICP's generated
code is full of those — the literals from the user's expression (the 1
in x^2+y^2==1) and the integer exponents CSE inserts (the 2 in x^2) —
so C.f([3..4, 5..6]) came back as [33.0, 51.0]_com_NG.

Wrapping the literals inside the symbolic expression doesn't survive:
Symbolics normalises ExactReal back to a plain number during its own
simplification. The fix has to happen on the generated Expr.

Add exactify(ex), which walks an Expr and wraps every non-Bool Real
literal in IntervalArithmetic.exact. Thread an exact::Bool = false
keyword through Contractor, Separator, and separator/constraint:

- make_function applies exactify to the build_function output before
  @RuntimeGeneratedFunction when exact=true.
- build_fb_contractor replicates RP's outer wrapper locally so it can
  exactify the body before RGF. When exact=false it forwards to
  forward_backward_contractor unchanged (no overhead in the default).

Default behaviour is unchanged; opting in gives
  julia> constraint(x^2+y^2==1, vars; exact=true).f([3..4, 5..6])
  [33.0, 51.0]_com

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
IEEE 1788 weakens intersect_interval(a, b) to the trv decoration
because, in general, the result may not be a subset of the range of
any function. Every reverse op in IntervalContractors is built on that
same intersect, so both the outer intersect_interval(_value,
_constraint) that RP emits and every narrowing step in the reverse
sweep drag trv through the contractor output. In HC4Revise, however,
each intersection/reverse-op is narrowing *within* an already-evaluated
function range, so min(decoration(inputs)...) is the valid decoration
— not trv.

Add preserve_decorations(ex) in src/utils.jl: a walker that rewrites
the body returned by ReversePropagation.forward_backward_expr so that
every IntervalArithmetic.intersect_interval call and every
ReversePropagation._rev_* reverse-op call has its output re-decorated
with min(decoration(inputs)...). Because Symbolics' toexpr emits the
call head as the actual function value (not Expr(:., Module, :name)),
the matchers compare ex.args[1] === IntervalArithmetic.intersect_interval
and parentmodule(f) === ReversePropagation && startswith(nameof(f), "_rev_")
directly.

_redecorate(x, d) unconditionally replaces the decoration (not min
with the op's own output decoration, which is precisely the weakened
trv we're overriding). Empty intervals stay trv (empty semantics).

build_fb_contractor now runs preserve_decorations alongside exactify
under exact=true. With both on:

  julia> constraint(x^2+y^2==1, vars; exact=true).contractor((-10..10, -10..10))
  [-1.0, 1.0]_com²   # was [-1.0, 1.0]_trv_NG²

(The outer of the Separator triple can still end up _trv because
Separator computes it via boundary ⊔ corner and hull intrinsically
weakens under IEEE 1788 — intended semantics.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant