sedumipy.pretransfo¶
Port of pretransfo.m: converts a user-facing (external) (At,b,c,K) SDP/ SOCP problem into SeDuMi’s internal format (real-only, Lorentz cones rearranged into trace+norm-bound blocks, rotated Lorentz cones converted to standard ones, diagonal SDP blocks folded into the LP block, complex SDP coefficients moved to the lower triangle, and a self-dual (x0,z0) variable appended).
This is a line-by-line port of a dense, index-arithmetic-heavy MATLAB file built around constructing one big sparse transformation matrix QR (via (row,col,value) triplet lists, one per cone-transformation kind) and applying it to At and c. See the .m file’s own comments for the mathematical meaning of each transformation; this docstring only calls out where the Python port diverges from a literal translation.
KNOWN UPSTREAM BUG NOT REPLICATED: pretransfo.m’s own line scplx(K.scomplex&~sdiag) = true; uses & (elementwise AND) between K.scomplex (a list of 1-indexed complex-SDP-block numbers) and ~sdiag (a length-L_s logical mask) as if it were an index-set assignment. This only happens to work when K.scomplex is empty, has exactly one element (scalar broadcasts against any vector), or has exactly L_s elements (sizes already match) – confirmed by direct reproduction against the real Octave build: K.s=[2;2;2]; K.scomplex=[1,3] crashes with “mx_el_and: nonconformant arguments (op1 is 1x2, op2 is 1x3)” inside pretransfo.m itself. This is a plain bug (not a deliberate or relied- upon behavior – nothing downstream depends on the crash), so unlike mineigK’s/eyeK’s bug-compatible quirks this is NOT replicated: this port uses the evidently-intended logic (scplx[K.scomplex-1] = True, an actual index-set assignment) so that declaring 2+ but not all SDP blocks complex actually works, matching what K.rsdpN/K.cdim’s own downstream formulas (nnz(sreal), sum(K.s(scplx).^2)) clearly assume scplx means: a boolean mask selecting the blocks in K.scomplex.
Functions
|
[At,b,c,K,prep,origcoeff] = pretransfo(At,b,c,K,pars) |