By: ValentinHirschi <valentin.hirschi@gmail.com>
ALL_GREEN: preserve independent CFF occurrences and simplify UV generation Keep repeated propagator occurrences independent through CFF construction. Select up to three certified derivative-energy assignments by actual native source-map count, preserving each selected assignment with its generated CFF. Add Spenso's intermediate_cost preset through the existing strategy selector; sparse_atom_aware remains available for rollback. Simplify direct/projected UV assembly and remove unused deferred state paths. Preserve direct per-residue subtraction, complete projected residue sums, frozen localizers and integrated ownership. Normalize valid zero projected sectors at their producer. Route child-soft carriers into the compatible parent chart before they become hard, preventing the GL08 finite counterterm from retaining an unintegrated inner momentum. Keep original owners, the strict CFF capacity guard and Vakint's analytic vacuum-numerator expansion. Advance saved-state format from version 5 to version 6 for the changed generated amplitude/cut-integrand state fields, rejecting older manifests before decoding. Regenerate pre-optimized states and their generated artifacts; no legacy migration is introduced. Numeric IntegrationState and integration- workspace version 1 are unchanged. Validation: three audit rounds and independent correction reviews complete; formatting, diff check, strict all-11-package check and Clippy passed on the UV-profile checkpoint, with all 1,864 source pins unchanged. The fresh seven- case UV-profile/GL20/ProcessRef campaign passed in 18.238 s with zero skips or retries. The fresh schema export and its profile-only overlay were independently reviewed. Final07 GL16 passed in 485.415 s versus 506.858 s for the published- compatible baseline (4.23% less time in one observation), with a 2.455 GB process-tree peak. Direct-route setup improved, while projected4D setup took 135.116 s versus 118.568 s (13.96% slower); no general generation speedup or isolated scheduler benefit is claimed. The final07 release scalar matrix passed all 166 cases once, using GL16 plus the disjoint remaining 165 with the same fresh catalogue/source/release-binary binding. There were no selected skips, retries, duplicates or failures. The two test wall times total 1,992.462 s, peak 2.455 GB; separate catalogue/build took 1,225.629 s, peak 19.901 GB. This is coverage-equivalent evidence, not one literal scalar-target invocation. Final candidate07's literal just test_gammaloop passed all 2,005 selected tests in 399.701 s, with zero selected skips, retries, failures or errors and a 1.315 GB process-tree peak. Independent catalogue/JUnit verification matched all 1,864 source pins and 39 selected native binaries. State save/load and manifest boundaries, settings, and all four DD/TT acceptance tests passed. All 14 scheduler semantic/timing runs succeeded with the complete inputs and aliases retained. Different BNL expression layouts compare exactly: after substituting 24 shared opaque subexpressions, their residual is zero in 0.13622 s. A prior broad normalization diagnostic timed out and is preserved. The external BNL fixture required five metric-metadata tag updates only; no terms or coefficients changed, and production source stayed frozen. With two observations per strategy in A,B,B,A order, GL20 network means were 3.366604 -> 2.783212 s (1.210x) and 3.786868 -> 2.624275 s (1.443x). Mean wall times were 3.969820 -> 3.275840 s and 5.462665 -> 3.283675 s; mean sampled peaks were 1.014 -> 0.538 GB and 3.467 -> 0.532 GB. BNL's roughly 2.65 -> 2.71 ms showed no meaningful change. These are short captured-input observations with limited memory samples, not universal speedups or exact lifetime memory bounds. Relevant full user prompts (later clarifications control earlier wording): --- User prompt 1 --- Proceed as follows: a) Finish the ALL\\\_GREEN run, getting the PR in a merge-ready state. Once you have all tests passing on your side, do not wait for the CI to complete before progressing to point b. Just periodically (every 1h or so) check on the status of that CI and address issues then, but do not let progress on b) be held up because this CI. b) Once this is done, create a feature branch based off this current higher power branch, with suffix "\\\_optimized". There you will explore the implementation of the following two optimizations:\ b.1) Make sure that the CFF construction never merges "degenerate" edges, and their rank, and keeps them separate throughout the entire CFF construction (so the residue map would have dedicated individual entry for these degenerate edges. Of course in the local UV from 4D approach, the final result is not residue-localized so that the various contribution of a given term of the UV forest, which could now have a residue map with keys of different length, do not really matter as you'd sum them directly with their appropriate numerator and end up with one expression to proceed further, without the residue map playing a role anymore. b.2) Optimal dispatch of the (S^0) type of energies, to minimize the maximal rank showing in the envelope, and in general preferring 2,2 to 3,1 even if there is a max of 4 elsewhere. b.3) Do a deep review of the construction of local UV from 3D and 4D to make sure the code is as clean, concise and flexible+understandable as it can be (leaving comments when warrented) to facilitate future maintenance of that code: it is a very tricky but important part of gammaloop. And also summarize where you're at currently. --- User prompt 2 --- I'd like you to also implement this "smarter scheduler" for spenso. Make sure that it's plug-and-play, i.e. the very nice abstraction of this "ContractionMethod" in spenso should make it very easy if need be to go back to the current scheduler, but indeed build your optimised one and make it default, we can keep it if it passes all the test (and in any case it'd be easy to revert). In general feel free to consider generic improvements in gammaloop, so long as they're truly generic and not too invasive (i.e. don't significantly increase code complexity). --- User prompt 3 --- Continue as planned, but indeed the idea is for the EMR dispatching of the "new pieces stemming from the derivatives) to minimize the number of residues in the residue map, this is what should in the end dictate your logic for where to dispatch, my earlier rules for the envelope rank minimization was just a proxy for this, but the actual figure of merit is the number of residues in the map. --- User prompt 4 --- Continue as planned, but proceed with at least 3 repeated rounds of audit before going and testing your finalised code on the tests to eventually push a green commit to the "...\_optimized" remote. --- User prompt 5 --- Continue as planned, but what do you mean with "removing Vakint’s expansion"? In order for vakint to process its vaccuum graph analytically, it needs to expand the numerator of its subgraph, and that's fine, no way out there.