`local_expectation` no longer works for row data if `dtype` is specified

[PietropaoloFrisoni]

local_expectation for MPS quantum circuits no longer works if dtype is specified.

Good morning/afternoon/evening, Mr. Gray, I hope you are doing well.

Last week, just after the release of quimb 1.9.0, we had some failures in our PennyLane test suite regarding the DefaultTensor device, which is based on quimb.

It seems to me that all the errors depend on the fact that providing dtype to the local_expectation method for the CircuitMPS class no longer seems to work. This is probably related to the fact that CircuitMPS.local_expectation has been specialized to make use of the MPS form in version 1.9.0.

The following is a minimal example to reproduce the error:

import pennylane as qml
import quimb.tensor as qtn
import numpy as np

cq = qtn.CircuitMPS(N=10)
op = qml.PauliZ(0)
cq.local_expectation(op.matrix(), where=[0], dtype=np.complex64)

With version 1.9.0, it fails with the following TypeError:

TypeError: _build_expression() got an unexpected keyword argument 'dtype'

On the other hand, the standard non-MPS circuit still works as expected, since

cq = qtn.Circuit(N=10)
op = qml.PauliZ(0)
cq.local_expectation(op.matrix(), where=[0], dtype=np.complex64)

correctly produces:

(1+0j)

We temporarily pinned quimb to the previous version in the latest version of PennyLane to avoid failures. If this is a bug in the new version of quimb, how hard would it be to fix it? Otherwise, do you recommend changing the approach to specify the dtype in the computation of local expectation values in the new quimb version?

As always, thank you so much for your help. All the best.

[jcmgray]

Thanks for the issue, should be quite easy to get a quick fix out for.

I suppose logically there is some difference between calling dtype here for a general TN and MPS circuit.

1. In the TN case, the dtype is just specifying what dtype to perform the actual contraction with, after the whole circuit has been constructed and simplified.
2. In the MPS case, the circuit has already been mostly 'contracted' eagerly as the gates have been supplied, so changing the dtype here just affects the last bit of computation / will not have that much affect / makes less sense.

Probably the best thing would be a dtype="auto" argument to the Circuit constructors, which can be overridden in specific methods. It would apply to the whole MPS simulation, but by default only to the contraction of full TN simulation. Would that cover your use cases?

[PietropaoloFrisoni]

Thanks for the issue, should be quite easy to get a quick fix out for.

That's great, thanks for the quick response.

I suppose logically there is some difference between calling dtype here for a general TN and MPS circuit.

1. In the TN case, the dtype is just specifying what dtype to perform the actual contraction with, after the whole circuit has been constructed and simplified.
2. In the MPS case, the circuit has already been mostly 'contracted' eagerly as the gates have been supplied, so changing the dtype here just affects the last bit of computation / will not have that much affect / makes less sense.

Yes, I agree.

Probably the best thing would be a dtype="auto" argument to the Circuit constructors, which can be overridden in specific methods. It would apply to the whole MPS simulation, but by default only to the contraction of full TN simulation.

Seems reasonable.

Would that cover your use cases?

Yes, I think so. We probably wouldn't even need to override the dtype argument in PennyLane (at least at the current stage) for specific methods; we could just set the dtype parameter in the constructor and the MPS_computational_state method (and potentially local_expectation). But in the near future we could benefit from greater flexibility in overriding parameters, so every additional feature you want to add is greatly appreciated 🚀

Thank you!