Sampling from circuit does not give proper bitstring

[VolodyaCO]

Issue Description

I am trying to sample from a 14 qubit circuit and I am getting a weird bitstring Array([0.5, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan], dtype=float32).

How to Reproduce

>>> import pickle
>>> import jax
>>> with open("faulty_circuit.pickle", "rb") as f:
...   circuit = pickle.load(f)
... 
Please first ``pip install -U qiskit`` to enable related functionality in translation module
An NVIDIA GPU may be present on this machine, but a CUDA-enabled jaxlib is not installed. Falling back to cpu.
>>> bitstrings_and_probs = circuit.sample(batch=2000, random_generator=jax.random.PRNGKey(3723))
>>> bitstrings_and_probs[1264][0]
Array([0.5, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan,
       nan], dtype=float32)

You can download faulty_circuit.pickle here (sorry for the very unsafe way of sharing this object, I am using custom gates and I don't want to paste the whole code here because it's quite bulky).

Error Output

There is no error, but clearly the outcome is wrong.

Environment Context

>>> tc.about()
OS info: Linux-5.19.0-46-generic-x86_64-with-glibc2.27
Python version: 3.11.7
Numpy version: 1.26.3
Scipy version: 1.12.0
Pandas version: 2.2.0
TensorNetwork version: 0.4.6
Cotengra is not installed
TensorFlow is not installed
Jax version: 0.4.23
Jax installation doesn't support GPU
JaxLib version: 0.4.23
PyTorch version: 2.1.2+cu121
PyTorch GPU support: True
PyTorch GPUs: [<torch.cuda.device object at 0x7f45847782d0>, <torch.cuda.device object at 0x7f4584778690>, <torch.cuda.device object at 0x7f4584778390>, <torch.cuda.device object at 0x7f45847794d0>, <torch.cuda.device object at 0x7f458477bd90>, <torch.cuda.device object at 0x7f4584779910>, <torch.cuda.device object at 0x7f458477bd50>, <torch.cuda.device object at 0x7f45ac112f10>]
Pytorch cuda version: 12.1
Cupy is not installed
Qiskit is not installed
Cirq version: 1.2.0
TensorCircuit version 0.11.0
>>> tc.__version__
'0.11.0'

[refraction-ray]

This is an interesting problem. Two remarks:

1. Does the same code work correctly for a plain circuit?

2. It would be better that the problem could be reduced to a minimal circuit with potential faulty gates, otherwise, I have to dig out which gate is problematic from c.to_qir() of the shared object anyway.

[VolodyaCO]

Hi @refraction-ray, what do you mean by a plain circuit? As per the potential faulty gate, the circuit takes the form of a cascade of two-qubit gates. This means, the circuit is a gate defined on qubits 0 and 1, then another one on qubits 1 and 2, and so on. Just one layer of this pattern. There is no gate defined on the last qubit and qubit 0. So, since the first bit in this sampling procedure gives 0.5 instead of 0 or 1, I would assume that it is the very first gate the faulty one.

[refraction-ray]

It seems that the exact code works well for a "plain circuit". So there must be something special in the definition of the faulty circuit in your case, could you pin down the source of the error by providing me a python code that generates the minimal faulty circuit?

[VolodyaCO]

Oh, so, the thing is that this is a completely random thing (I just happened to hit the error for this particular random key). I think that whatever is wrong with the circuit could be deduced from the first gate of the circuit I shared, which should be a custom two-qubit SU4 gate