[FBumann]

Prompt: And what of this is a bug on main that should land there independently?

Note

The following content was generated by AI.

A quadratic constraint whose block drops a row with no term now keeps each quadratic pair on its own row. Before, a later row took an earlier row's pair and lost its own, and the wrong model solved silently.

Cause, test, gates, what was not done

Cause. _drop_termless_rows renumbered rows and the matrix share, but not the quadratic share. _block then filtered the quadratic share against the renumbered rows. So an entry kept its old row number and landed on the wrong row, or was dropped.

Test, written first as a strict xfail and watched to fail on af1dac7: test_a_quadratic_row_keeps_its_own_pair_when_a_row_before_it_is_not_built. k * p * p <= 10 over g=[a,b,c] with k only at b, c. On main, qmatrix is [(1, 1, 1, 1.0)] where [(0, 1, 1, 1.0), (1, 2, 2, 4.0)] is correct. The test also solves with Gurobi against the optimum worked out by hand.

Fix. _drop_termless_rows takes the quadratic share and renumbers it with the same map. The filter in _block goes, because every row the quadratic share holds is in kept. replace_strict raises if that ever stops being true.

Gates, in a uv venv on polars 2.0.0 (no pixi in this container): ruff check . and ruff format --check . at 0.16.9, pyrefly check on src/ at 1.3.1 (0 errors), pytest -n auto tests: 5449 passed, 657 skipped, 4 xfailed, and 2 failed. The 2 failures are the [xpress] cases, which fail on main too because the xpress package is not installed here. docs-test was not run.

Not done.

• _drop_termless_rows has a second caller in _build_constraint, for a constraint with no linear and no quadratic term. That caller now passes None for the quadratic share. No test reaches that branch: the suite stays green with it replaced by a raise. The loader refuses a constraint with no variable, so the branch looks unreachable. perf(engine): a model with many variables and constraints builds about 15% faster #2022 removes it.
• The omitted-row count of the same function is a separate bug, fixed in fix(engine): the rows a restriction removed and the rows with no term are reported together #2029.
• perf(engine): a model with many variables and constraints builds about 15% faster #2022 rewrites this function. When it merges main, the resolution keeps its version and adds this renumbering; fix(engine): a quadratic row keeps its own pair when a row before it has no term #2027 already has it there.

🤖 Generated with Claude Code

https://claude.ai/code/session_013DSGmeGQfUxE4gyNQy94qG

[read-the-docs-community]

Documentation build overview

📚 specsolve | 🛠️ Build #35118009 | 📁 Comparing 9fb6084 against latest (af1dac7)

  🔍 Preview build  

1 file changed

± about/changelog/index.html

[codspeed]

Merging this PR will degrade performance by 12.86%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 7 regressed benchmarks
✅ 97 untouched benchmarks
⏩ 307 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	test_emit[network-s-specsolve-in-memory-lp]	28.2 MB	34.5 MB	-18.2%
❌	test_emit[network-s-specsolve-lp]	28.2 MB	34.5 MB	-18.2%
❌	test_emit[network-s-specsolve-highs]	19.5 MB	21.8 MB	-10.7%
❌	test_emit[network-s-specsolve-in-memory-highs]	19.5 MB	21.8 MB	-10.69%
❌	test_window[network-s-specsolve-highs-cold]	19.6 MB	21.9 MB	-10.65%
❌	test_window[network-s-specsolve-highs-coefficient]	19.6 MB	21.9 MB	-10.54%
❌	test_window[network-s-specsolve-highs-shape]	19.5 MB	21.8 MB	-10.54%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing fix/quadratic-rows-renumbered (9fb6084) with main (b646d61)²}

Footnotes

1. 307 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (af1dac7) during the generation of this report, so b646d61 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩