Template Function sequant::eval::evaluate_ordered_multiroot

Function Documentation

template<Trace EvalTrace = Trace::Default, meta::can_evaluate_range Nodes, typename F, typename N, bool FHC, typename ScopeGuardFactory = ::sequant::make_no_scope_guard>
container::svector<ResultPtr> sequant::eval::evaluate_ordered_multiroot(Nodes const &roots, OrderedSchedule const &ordered, RichSchedule const &rich, container::svector<std::string> const &layouts, F const &leaf_evaluator, CacheManager<N, FHC> &cache, std::function<std::size_t(Index const&)> const &target, ScopeGuardFactory const &make_scope_guard = {}, std::function<bool(std::ranges::range_value_t<Nodes> const&)> const &is_volatile = {})

The multi-root ordered entry point. Identical inputs to evaluate_ordered_schedule (same roots/ already have been built from the same concatenated roots, e.g. via compute_dag_boulevard(roots, ...)

  • build_ordered_schedule, exactly as any evaluate_ordered_schedule caller already does for its own forest), except layout widens to layouts, one entry per root: unlike a single summed forest, independent roots need not share a layout (e.g. distinct CC residual annotations R1 {a;i} vs R2 {ab;ij}). Returns a map instead of a sum: each root’s own (permuted to its own layouts entry, but not cross-root-accumulated) result, aligned index-for-index with roots.

    Runs the identical schedule walk evaluate_ordered_schedule runs (via the same detail::run_ordered_schedule_pre_results this function and evaluate_ordered_schedule both delegate to &#8212; the cell table derivation and the run-completeness assert are unchanged, exercised over the combined schedule exactly as they already are for a multi-summand forest), so a value shared across two independent roots is built exactly once for the identical reason a value shared across two summands of one root’s own forest already is: compute_dag_boulevard buckets by structural hash into one ValueCell regardless of which root(s) reference it, and well_formed's static single-producer invariant (plus this walk’s own run-completeness assert) guarantees the schedule realizes exactly one BuildStep for it. The only change from evaluate_ordered_schedule is the tail: instead of one forest-wide combine_forest_roots call (which sums every root into a single ResultPtr), this calls combine_forest_roots once per root, each with a singleton {roots[i]}/{pre_results[i]} pair &#8212; reusing the identical per-root Term/Permute trace bookkeeping combine_forest_roots already emits for each root of a summed forest, but never reaching its cross-root add_inplace (a singleton call never has a second root to sum against), so no roots are summed together. For a single-root roots input this reduces to a singleton combine_forest_roots call byte- identical to what evaluate_ordered_schedule would run for that same one-root forest &#8212; the regression anchor: evaluate_ordered_multiroot( {r}, …) == { evaluate_ordered_schedule({r}, …) }.

Returns:

One ResultPtr per element of roots, in roots' own order, each permuted to its own layouts entry &#8212; not summed together.