Allow Sparse Unitaries in the `Operator` Interface

[valentinpi]

What should we add?

For a project, we want to use very large and sparse unitaries. scipy already provides the scipy.sparse.coo_array interface [1], which behaves just like an array, but uses much less memory. We would really appreciate it, if the Operator interface could be extended to use sparse arrays.

[1] https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.coo_array.html#scipy.sparse.coo_array, last accessed: 05.07.2024, 10:02.

[Cryoris]

The SparsePauliOp allows to represent operators as sums of Paulis. Since you're dealing with unitaries in the context of quantum computing chances are, you could efficiently represent your matrices as such. Would that work in your use-case?

[valentinpi]

I am aware of the SparsePauliOp class, but to utilize it, we would need to convert our operator from a sparse matrix to a Pauli list and that is not trivial to do, though it is always possible, as the Pauli operators generate the Hilbert space.

I have also looked into the Qiskit code for Operator. Would it suffice to extend its initialization and to_instruction() methods to allow for a sparse matrix and to adjust the evolve method? I think the Instruction class also needs to be modified, but is there more? My general intuition was, that we need to adjust the matrix multiplication used in applying the unitary to a state, and that should be sufficient, besides safety checks.

[jakelishman]

Operator is at this point well-defined to be a dense-matrix representation - it's very non-trivial to change that.

Fwiw, Qiskit is not really a library for general matrix-based quantum-information manipulations. We have some capability for it, but it's primarily in service of the synthesis and optimisation of gate-model computations, at qubit scales beyond what even sparse matrices can represent. What parts of Qiskit are you intending to use with these sparse operators? Would a library better-suited to matrix-model quantum information like QuTiP better serve you?

[valentinpi]

Thanks for the explanation, I didn't think it was obvious from the concept of the library itself. Some notes on the documentation about what you said would be great. And thanks for the suggestion, but I did not find sparse unitaries in the QuTiP library.

Generally, we use Qiskit, as it provides generally better functionality and clearer semantics when writing simulations for quantum algorithms, than just matrix-multiplying some arrays together and doing a measurement manually. My goal was to use the append function of a QuantumCircuit with an Operator defined by some matrices. As stated above, these operators are very sparse, so it would be good to reduce dimensionality, as we know the indices of filled entries. Otherwise, Qiskit is just too slow.

I have now implemented the following approach: Prepare a part of the circuit, read out its statevector, multiply manually by the unitary (i.e., evolve) and create a new circuit with the initialization of this state, apply the other gates we have, and then measure manually, as I have found, that the transpilation process takes too long, if a large statevector initialization is performed. Qiskit thus allows for the first and last part of the circuit to be coded with a few lines, while the middle and end parts are not that hard nor long to do (i.e., just a .dot and a choices call).

As far as I understand it, there are no plans to change the Operator interface as suggested above. I would like to kindly ask, if you would have some recommendations or improvements to the approach I just outlined, please?