Library of commutation relations over standard gates

[kdk]

What is the expected enhancement?

From @jakelishman 's comment in #6982 (comment) :

There is more work that could be done here as well, which I think would give us more performance in more natural workflows that don't just involve dumping in a tonne of unitary matrices. The next obvious step would be to build a lookup table of gate types that are known to commute with each other, in order to skip the entire process of comparing the two matrix multiplications for common cases; we can always fall back to this method. I haven't done this right now, because it's bigger task, and doesn't need doing in one go.

[jakelishman]

To add to this: sensibly, the "lookup table" is probably something like a dictionary of (gate_type_1, gate_type_2) -> callable, where the callables take the actual gate instances and the qubits they operate on. Then they can return True, False, or None depending on whether they know they definitely commute, definitely don't commute, or they're not sure, by fast methods, such as inspecting the parameters. If we get None back, or there's no callable for the given types, we can just fall back to the current multiplication methods.

The callables won't play super nicely with the current caching method, but if they're fast enough, we may well not care that much. This form of type-based lookup also doesn't work "right" with inheritance, but if someone's inheriting from XGate, it's probably not our fault if things don't work right after.

[clausia]

I'm interested in doing this enhancement

[jakelishman]

Done by #11192.