Follow-up from #55 (suggested by @samtalki).
Today the KKT system's shape is reached through a few separate entry points:
kkt_dims(net|prob) and kkt_indices(net|prob) (public), backed by the
internal _dc_kkt_layout, _dc_kkt_dims, and _dc_kkt_indices helpers (and the
AC equivalents). _dc_kkt_layout already returns the (dim, idx) pair that most
call sites actually want.
Proposal: elevate a single kkt_layout(net|prob) (returning the dimension plus
the named index ranges together) to the primary public interface for the KKT
system, and document it as the entry point, with kkt_dims/kkt_indices kept as
thin conveniences. This gives callers one consistent handle on the layout and
reduces the chance of dims and indices drifting apart.
Worth doing for both the DC and AC KKT systems so the interface is uniform.
Follow-up from #55 (suggested by @samtalki).
Today the KKT system's shape is reached through a few separate entry points:
kkt_dims(net|prob)andkkt_indices(net|prob)(public), backed by theinternal
_dc_kkt_layout,_dc_kkt_dims, and_dc_kkt_indiceshelpers (and theAC equivalents).
_dc_kkt_layoutalready returns the(dim, idx)pair that mostcall sites actually want.
Proposal: elevate a single
kkt_layout(net|prob)(returning the dimension plusthe named index ranges together) to the primary public interface for the KKT
system, and document it as the entry point, with
kkt_dims/kkt_indiceskept asthin conveniences. This gives callers one consistent handle on the layout and
reduces the chance of dims and indices drifting apart.
Worth doing for both the DC and AC KKT systems so the interface is uniform.