Qubits violating linear type

[jon-wurtz]

The following is very much an invalid program:

@squin.kernel
def main():
    qb = squin.qubit.new(1)
    squin.gate.cx(qb[0], qb[0])

and yet runs through the simulator just fine. This violates the no-cloning theorem.

[Roger-luo]

We do not have any validation implemented/planned to implement this quarter.

We have something upcoming for validating the non-cloning error by just checking the SSA dataflow.

[cduck]

I'm curious how pyqrack accepts this...

[Roger-luo]

tagging @WrathfulSpatula in case you are interested to take a look from pyqrack side.

[WrathfulSpatula]

This is a "garbage-in, garbage-out" case. To be clear, Qrack validates that no requested input qubits will produce a segmentation fault, by being out-of-range. But it doesn't validate that all qubits are unique, necessarily. I need to think about when and whether that would be appropriate. (From Qrack's side, it's not necessarily just a matter of respecting no-cloning, which is an artificial constraint for a simulator anyway; it's potentially also whether any "side-effect" of the undefined behavior has meaningful application to GPU kernels with denormalized amplitude vectors. What I mean, for example, is that we once had a user interested in Laplace transforms, rather than Fourier transforms: you could "hack-around" the usual expectation of normalization in Qrack to directly produce a Laplace transform as a state vector output. Quantum realism isn't our sole utility.)

[WrathfulSpatula]

So, I traced this code for this and similar cases, and it doesn't produce a segmentation fault, even in any edge or corner case, but it does denormalize the state vector, potentially. As such, I'd prefer not to explicitly prohibit it in Qrack, because we've had users who were specifically interested in dernomalized cases before, like I explained, and so it's hard to say on what undefined behavior cases a small segment of users depend. (Qrack's rule-of-thumb has always been to get the expressly defined cases exactly right, to validate against segmentation faults, and to otherwise let users "abuse" the API however they deem fit, if that's what they really want.)

[WrathfulSpatula]

(Actually, if I managed to trace this by hand accurately, that specific cx operation might be an undefined-behavior alias for "no-op." But the code path in Qrack has like ~90% in common with cz, or cy, or mcu, or controlled matrix operator gates, and, in terms of the overall design philosophy, it makes things inconsistent, to specifically prohibit this.)