Problem
Neither apply() nor compress() validates its arguments, so invalid input
either produces silent garbage or surfaces as a confusing error from deep
inside NumPy or opt_einsum.
Measured behaviour on main:
| Input |
Current result |
chi_out=0 |
No error. Returns an MPO whose every bond is 0 — silent garbage |
chi_out=-3 |
ValueError: negative dimensions are not allowed (from NumPy) |
cutoff=2.0 |
No error. Every bond silently collapses to 1 |
cutoff=-1.0 |
No error. Silently treated as "no truncation" |
apply() with left.nsites != right.nsites |
ValueError: Einstein sum subscript 'de' does not contain the correct number of indices... |
The chi_out=0 case is the worst: a caller who computes chi_out from some
other quantity and gets 0 receives a well-formed but meaningless tensor
network with no indication that anything went wrong.
There is also an unchecked structural assumption: _, phys_up, phys_down = mpo.arrays[0].shape requires a rank-3 boundary tensor, so an MPO with
non-open boundary conditions fails with an opaque unpacking error.
Proposed fix
Validate at the public API boundary — in apply() and compress() — and raise
clear, actionable errors before any computation starts:
chi_out must be an integer >= 1; raise ValueError otherwise, naming the
argument and the offending value.
cutoff must satisfy 0.0 <= cutoff < 1.0; it is a relative threshold on
the largest singular value, so a value >= 1 discards everything and is
never meaningful. Raise ValueError otherwise.
- In
apply(), require left_tensor.nsites == right_tensor.nsites and raise a
ValueError naming both counts.
- Check that the boundary tensors have the expected rank and raise a
ValueError explaining that only open boundary conditions are supported.
Keep the messages specific enough to debug from a traceback alone, and follow
the existing EM/TRY ruff rules (message assigned to a variable first).
Acceptance criteria
Problem
Neither
apply()norcompress()validates its arguments, so invalid inputeither produces silent garbage or surfaces as a confusing error from deep
inside NumPy or
opt_einsum.Measured behaviour on
main:chi_out=00— silent garbagechi_out=-3ValueError: negative dimensions are not allowed(from NumPy)cutoff=2.0cutoff=-1.0apply()withleft.nsites != right.nsitesValueError: Einstein sum subscript 'de' does not contain the correct number of indices...The
chi_out=0case is the worst: a caller who computeschi_outfrom someother quantity and gets
0receives a well-formed but meaningless tensornetwork with no indication that anything went wrong.
There is also an unchecked structural assumption:
_, phys_up, phys_down = mpo.arrays[0].shaperequires a rank-3 boundary tensor, so an MPO withnon-open boundary conditions fails with an opaque unpacking error.
Proposed fix
Validate at the public API boundary — in
apply()andcompress()— and raiseclear, actionable errors before any computation starts:
chi_outmust be an integer>= 1; raiseValueErrorotherwise, naming theargument and the offending value.
cutoffmust satisfy0.0 <= cutoff < 1.0; it is a relative threshold onthe largest singular value, so a value
>= 1discards everything and isnever meaningful. Raise
ValueErrorotherwise.apply(), requireleft_tensor.nsites == right_tensor.nsitesand raise aValueErrornaming both counts.ValueErrorexplaining that only open boundary conditions are supported.Keep the messages specific enough to debug from a traceback alone, and follow
the existing
EM/TRYruff rules (message assigned to a variable first).Acceptance criteria
ValueErrorwith a message naming the argument and value.