Inconsistent Real-Valued dtype Support Across cuTensorNet Interfaces for Expectation Value Computation

[seba2390]

We’ve encountered a key inconsistency in cuQuantum’s current API: support for real-valued dtypes (float32 / float64) is not uniformly available across the different ways to construct and contract tensor networks, even when the underlying quantum circuit and Hamiltonian are entirely real.

We’re working on a quantum chemistry project using cuTensorNet (via cuQuantum Python) to compute expectation values of the form ⟨ψ|𝐻|ψ⟩. In many cases, the circuits and Hamiltonians are purely real—containing only gates and operators that preserve realness. In such situations, representing the tensor network with real dtypes would reduce memory usage and likely improve performance.

As of cuQuantum 25.03.0, there are multiple pathways to construct and contract these tensor networks:

1. Use cuquantum.tensornet.CircuitToEinsum → .expectation(...)
2. Use cuquantum.tensornet.experimental.NetworkState:
   2.1. via .from_converter(...) → .compute_expectation(...)
   2.2. via .from_circuit(...) → .compute_expectation(...)
3. Manually build a NetworkState and apply gates with .apply_tensor_operator(...)
4. Construct the einsum string and TN manually → cuquantum.tensornet.contract(...)
5. Other combinations or custom workflows

However, only some of these pathways allow specifying a real dtype. For example:
Interfaces (1) and (2) force the use of complex64/complex128 even for purely real circuits.
Manual construction (options 3 and 4) do allow real-valued dtypes via NetworkState and NetworkOperator.
This inconsistency makes the development process more complex and may unnecessarily degrade performance for real-valued cases. From a user’s perspective, it would be highly beneficial if all interfaces—regardless of abstraction level—supported real dtypes when applicable.

A more consistent and flexible dtype policy would improve both usability and performance for a wide range of practical applications.

Best regards,
Sebastian Yde Madsen

[yangcal]

Hello Sebastian,

Thanks for sharing the feedback. We will improve our APIs in a future release. Meanwhile for the path-route 1, you may temporarily get around it via

expr, operands = converter.expectation(...)
operands = [o.real for o in operands]
out = contract(expr, *operands)