Skip to content

Validate public API arguments: chi_out=0 silently returns zero-size bonds #15

Description

@Panadestein

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

  • Each invalid input above raises ValueError with a message naming the argument and value.
  • Validation happens before any array allocation.
  • Parametrised tests cover every case in the table.
  • Valid input behaviour is completely unchanged.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions