ClassicalStateSimulator should support CSWAP gate

[NoureldinYosri]

Is your feature request related to a use case or problem? Please explain

ClassicalStateSimulator currently supports X, CNOT, Toffoli, SWAP and Permutations but it should also support CSWAP gate.

It should also allow passing an initial state in the form of a tuple of ints, currently it accepts only a list and an ndarray

How urgent is this for you? Is it blocking important work?

P3 – I'm not really blocked by it; it's an idea I'm proposing based on principle

[Adithyaphani]

Is the issue still open ? If yes is it possible to assign this task to me

[NoureldinYosri]

thanks @Adithyaphani for offering to help, I assigened it to you

[daxfohl]

It might be worth it to do something like https://github.com/cduck/cirqtools/blob/master/cirqtools/classical_simulator.py#L135-L149 on the unitary instead of all the if/else branches. It'd be more flexible, and I've definitely seen cases where something that looks like a complex numpy op outperforms a simple python branch. It'd still be linear on number of qubits in the circuit; only exponential in the number of qubits in the gate, which is currently being limited to 3 anyway.

[rosspeili]

@daxfohl I can rework it to follow this method, but it was a very simple inclusion fix. @NoureldinYosri what do you think of the pr?

[NoureldinYosri]

@rosspeili the PR looks good, thanks

@daxfohl I think a specialized simulator that just looks at specific gates is okay for the purpose of this case. the potential gain of numpy array over if/else will probably be lost due to using complex numbers to represent the state and applying 3-qubit gates. if you feel strongly about it, we can add it as a fallback mechanism

[daxfohl]

Nah I don't have a strong opinion, just wanted to mention it as a possibility. It'd give classical simulation support for parity gates, phase gates, Y gates, anything that could be factored into a permutation plus a diagonal, for free.

But wrt perf, I have definitely had cases where I've tried adding a simple "if x == 0" or whatever guard to avoid some complex looking numpy op in some cases where I knew the op would have no effect, and was surprised to find that it actually made things slower. IDK whether that would be the case here or not, but if y'all ever do add it as a fallback option, remember to double check the perf to see whether it should actually be the primary option.

[daxfohl]

NB: I tried that algo as a replacement, and yeah it's slower than the isinstance checks.

Just for comparison/education sake, here's the case I encountered a while back where a matrix multiplication was faster than a single branch check: #5917 (comment). Looking into it, the reason for the difference is that in that case, the numpy kernel already existed, and without the if branch it could pipeline the ops for roughly zero cost. With the if "optimization", it broke the pipeline and ended up being more expensive. In the current case however, it'd be creating a new numpy kernel from scratch, which is a lot more expensive than a python if isinstance check/branch.

So, it'd still be useful as a fallback option, but we'd still want to keep the isinstance checks first.