You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: const-ify Lu::det, Ldlt::det, inf_norm, det_errbound, and solve methods #86
Several public methods that are pure computation over [f64; D] / [[f64; D]; D] arrays could be const fn today but aren't. This would enable compile-time evaluation and is consistent with the existing const fn pattern established by det_direct, Vector::dot, etc.
Depends on: #67 (MSRV bump to 1.95, which stabilizes additional const-compatible float intrinsics) and #85 (fix inf_norm before const-ifying it)
Candidates
Easy (no trait methods, just loops and float ops)
Lu::det — loop over diagonal with multiply-accumulate. Straightforward.
Ldlt::det — same pattern as Lu::det.
Matrix::inf_norm — needs manual loop replacing .iter().map().sum() (iterators aren't const-stable). Also depends on f64::abs() being const — check availability at MSRV 1.95.
Matrix::det_errbound — uses f64::abs() and mul_add. Same abs() dependency.
Moderate (manual loops replacing iterator chains)
Lu::solve_vec — the forward/back substitution loops are already manual; the iterator-based inner loops (enumerate().take(i), enumerate().skip(i+1)) would need conversion to while loops. The is_finite() check needs to be const-compatible.
Ldlt::solve_vec — same pattern as Lu::solve_vec.
Blocked (needs generic_const_exprs or other unstable features)
gauss_solve and exact methods — use BigInt/BigRational heap types, not const-eligible
Activity
acgetchell commentedon Apr 14, 2026
Blocked by #67 (needs MSRV 1.95 for const float intrinsics) and #85 (inf_norm fix should land before const-ifying it).
Changed: finalize documentation, benchmarks, and error handling
Changed: consolidate and expand const-evaluability tests via macros