[baggepinnen]

Fixes three defects of branch and bound on dyad. A codex review of JuliaComputing/daqp#2 found them in code that predates that PR.

1. Priority list with equality reduction (introduced in ef72ae7). daqp_set_branch_priority stores indices of the original problem. When an equality elimination is installed, daqp_get_branch_id used them as indices of the reduced problem, which reads beyond work->sense; AddressSanitizer reports a heap-buffer-overflow. The indices are now mapped through eq->keep, which is in ascending order of the original index, so the lookup is a binary search; eliminated constraints are skipped. Code generation of a reduced problem writes the mapped list.
2. Generated tree storage (since 9393ffb). Generated code declared tree_WS[(n+1)(nb+1)], while setup_daqp_bnb allocates (n+ns+1)(nb+1), because soft constraints can be part of a stored working set. With ten soft constraints the generated array has 6 entries and the root working set writes 10. The generated size now includes the soft constraints of the generated problem.
3. Default objective bound.
   • DAQP_INF = 1e30 is finite. The bound was shifted by the offset c = 0.5||v||^2 - fp only when rel_subopt, fval_bound or lb was set. With the default bound it was therefore compared with the internal objective J + c instead of J.
   • Example: 0.5x^2 + 2e15 x with x binary is reported infeasible instead of x = 0 with objective 0.
   • The offset is now always added (O(n) per branch-and-bound solve).
   • Consequence: problems whose objective J itself exceeds 1e30 are still pruned, but problems with a large c and a moderate J are no longer. This is the behaviour the parallel solve in JuliaComputing/daqp#1 needs, since it shares the bound on J between threads.

Not changed: the continuous solver daqp_ldp (no binaries) still compares 2*fval_bound with the internal objective without c.

Tests

• New interfaces/daqp-eigen/tests/32_bnb_regressions.cpp, one case per defect.
• On dyad without this change: cases 2 and 3 fail, and case 1 aborts under AddressSanitizer.
• With the change: all pass, also under AddressSanitizer. ctest 32/32, Julia suite 1479/1479.

---

Host: demeter2, session session_01JGy8Ya4ZvmiQUA33aivGGJ, working directory /tmp/daqpfork

🤖 Generated with Claude Code

[baggepinnen]

Consequence of item 3 for data whose linear term is of the order of DAQP_INF (e.g. the LinearMPC example invpend_contact, with a linear term of about 1e30): c is then so large that DAQP_INF + c equals c in floating point, and the objective J cannot be resolved. Before this change such a problem was reported infeasible at the root (since J + c > DAQP_INF); now the search proceeds and, on invpend_contact with presolve, ends at the time limit with an incumbent of objective 1.8e44. Without presolve it is still reported infeasible. The data of that example are not meaningful (a linear term equal to the value that represents infinity), so I did not add special handling; a check for |c| beyond the resolution of DAQP_INF would be possible if the previous behaviour is preferred.