Clifford-specific protocols #4639

daxfohl · 2021-11-08T23:08:18Z

Is your design idea/issue related to a use case or problem? Please describe.

Would be a step in #4582 (comment), but probably also valuable on its own.

Describe your design idea/issue

Currently there's no low-level way to update a Clifford tableau or ch-form given a gate, i.e. there's no equivalent to apply_unitary. Clifford transforms are all done via the act_on protocol, which requires a lot of additional setup to use. It would be nice to have a low-level protocol like apply_to_tableau(gate, tableau, axes), that allows one to interact with a tableau natively without the act_on ceremony. Similar with ch-forms.

Once these exist, we can remove all the act_on isinstance checks and just allow the simulators to fall back naturally to the apply_to_tableau functions. Once this is done, simulators will all function consistently: use act_on for "control" logic (subcircuits, classical controls) and use quantum-state-representation-specific protocols for all quantum calculations.

The text was updated successfully, but these errors were encountered:

daxfohl · 2021-11-16T18:59:04Z

As noted in the linked PR, while I think this is an improvement, I don't think this is the best solution. The best option would be a protocol that just returns some representation of the gate in a way that any Clifford simulator can use. That would allow 3rd-party Clifford simulators to be built, whereas this current PR is locked to the two cirq.clifford simulators and I believe puts too much state-representation-specific logic into the gates themselves.

If such a thing is possible I'd say we should do that instead. I don't know stabilizer theory well enough to know if such a thing is possible though. (Upon quick review of M&I, it looks like a get_pauli_factors(): Sequence[Tuple[PauliId, Angle, Axis]] (where pauliId is an enum of I,X,Y,Z and angle is one of 1, -1, i, -i) would be sufficient?)

tanujkhattar · 2021-11-17T19:13:24Z

Discussion from the sync:

It'd be nice to have consistency across the library. We should have an RFC with more concrete questions.
It should be nice to have the library be able to support custom clifford simulators but do we have use cases where such custom clifford simulators would be useful?
More concrete questions should clarify the future direction.

daxfohl · 2021-11-20T19:55:12Z

@tanujkhattar @viathor tinyurl.com/clifford-simulators-refactor

tanujkhattar · 2022-01-05T19:24:35Z

Discussion from sync:

@viathor Can you please take a look at this?

@tanujkhattar

Fixes #4639, ref [tinyurl.com/clifford-simulators-refactor](https://tinyurl.com/clifford-simulators-refactor) This change makes the Clifford simulators more consistent with other simulators. Rather than the gate having all the logic of how to update the simulator state, which seemed out-of-place and limited the ability to reuse in any new kinds of Clifford simulators, this PR moves all the logic to the simulators themselves. It also creates an ABC for Clifford simulator states, allowing reuse of the evolution logic in the base class, such that the subclasses just have to implement the specific gate applicators. Note I *tried* doing this via a new Clifford protocol as well ([link](https://github.com/quantumlib/Cirq/compare/master...daxfohl:clifford3?expand=1)) as we originally discussed, and it works but I didn't like the result. The protocol ended up just duplicating all the information of the gate, in a weird structure, and felt like an extra, unnecessary, hacky wrapper around just using the gate itself. So I prefer the approach in this PR that just uses the gate instances directly, though I'm open to suggestion. @tanujkhattar @viathor (cc @ybc1991)

@tanujkhattar

…#4748) Fixes quantumlib#4639, ref [tinyurl.com/clifford-simulators-refactor](https://tinyurl.com/clifford-simulators-refactor) This change makes the Clifford simulators more consistent with other simulators. Rather than the gate having all the logic of how to update the simulator state, which seemed out-of-place and limited the ability to reuse in any new kinds of Clifford simulators, this PR moves all the logic to the simulators themselves. It also creates an ABC for Clifford simulator states, allowing reuse of the evolution logic in the base class, such that the subclasses just have to implement the specific gate applicators. Note I *tried* doing this via a new Clifford protocol as well ([link](https://github.com/quantumlib/Cirq/compare/master...daxfohl:clifford3?expand=1)) as we originally discussed, and it works but I didn't like the result. The protocol ended up just duplicating all the information of the gate, in a weird structure, and felt like an extra, unnecessary, hacky wrapper around just using the gate itself. So I prefer the approach in this PR that just uses the gate instances directly, though I'm open to suggestion. @tanujkhattar @viathor (cc @ybc1991)

@daxfohl

Add initial Clifford Gate with multiple qubits. Compared with SingleQubitCliffordGate, it has fewer functionalities since we cannot enumerate all of them with PauliGates and several special single qubit properties like Bloch rotation no longer exist. Anyway, it provides several basic interactions: 1. It uses Clifford tableau as underlying data representation (different from the state representation). 2. It can be constructed from a tableau or list of operations (`_has_stabilizer_effect_` only). All Clifford gates can be built through \{S, H, CNOT\}, so we can construct any Clifford Gate from the list of operations. We just cannot pre-define it. 3. Decomposing into several basic operations. 4. Get unitary matrix through decomposing (we cannot do this in a reverse way from unitary to Clifford gate :( ). 5. Know how to interact with ActOnCliffordTableauArgs, i.e. it should be able to use with CliffordTableau simulator (Looks like we don't have that in cirq yet? @daxfohl will add that? see #4639 and #4748.). This PR is part of efforts for #3639. Context: this PR doesn't introduce any new algorithms but the key methods are already implemented in #4183 and #4096.

@daxfohl

Add initial Clifford Gate with multiple qubits. Compared with SingleQubitCliffordGate, it has fewer functionalities since we cannot enumerate all of them with PauliGates and several special single qubit properties like Bloch rotation no longer exist. Anyway, it provides several basic interactions: 1. It uses Clifford tableau as underlying data representation (different from the state representation). 2. It can be constructed from a tableau or list of operations (`_has_stabilizer_effect_` only). All Clifford gates can be built through \{S, H, CNOT\}, so we can construct any Clifford Gate from the list of operations. We just cannot pre-define it. 3. Decomposing into several basic operations. 4. Get unitary matrix through decomposing (we cannot do this in a reverse way from unitary to Clifford gate :( ). 5. Know how to interact with ActOnCliffordTableauArgs, i.e. it should be able to use with CliffordTableau simulator (Looks like we don't have that in cirq yet? @daxfohl will add that? see quantumlib#4639 and quantumlib#4748.). This PR is part of efforts for quantumlib#3639. Context: this PR doesn't introduce any new algorithms but the key methods are already implemented in quantumlib#4183 and quantumlib#4096.

@tanujkhattar

…#4748) Fixes quantumlib#4639, ref [tinyurl.com/clifford-simulators-refactor](https://tinyurl.com/clifford-simulators-refactor) This change makes the Clifford simulators more consistent with other simulators. Rather than the gate having all the logic of how to update the simulator state, which seemed out-of-place and limited the ability to reuse in any new kinds of Clifford simulators, this PR moves all the logic to the simulators themselves. It also creates an ABC for Clifford simulator states, allowing reuse of the evolution logic in the base class, such that the subclasses just have to implement the specific gate applicators. Note I *tried* doing this via a new Clifford protocol as well ([link](https://github.com/quantumlib/Cirq/compare/master...daxfohl:clifford3?expand=1)) as we originally discussed, and it works but I didn't like the result. The protocol ended up just duplicating all the information of the gate, in a weird structure, and felt like an extra, unnecessary, hacky wrapper around just using the gate itself. So I prefer the approach in this PR that just uses the gate instances directly, though I'm open to suggestion. @tanujkhattar @viathor (cc @ybc1991)

@daxfohl

Add initial Clifford Gate with multiple qubits. Compared with SingleQubitCliffordGate, it has fewer functionalities since we cannot enumerate all of them with PauliGates and several special single qubit properties like Bloch rotation no longer exist. Anyway, it provides several basic interactions: 1. It uses Clifford tableau as underlying data representation (different from the state representation). 2. It can be constructed from a tableau or list of operations (`_has_stabilizer_effect_` only). All Clifford gates can be built through \{S, H, CNOT\}, so we can construct any Clifford Gate from the list of operations. We just cannot pre-define it. 3. Decomposing into several basic operations. 4. Get unitary matrix through decomposing (we cannot do this in a reverse way from unitary to Clifford gate :( ). 5. Know how to interact with ActOnCliffordTableauArgs, i.e. it should be able to use with CliffordTableau simulator (Looks like we don't have that in cirq yet? @daxfohl will add that? see quantumlib#4639 and quantumlib#4748.). This PR is part of efforts for quantumlib#3639. Context: this PR doesn't introduce any new algorithms but the key methods are already implemented in quantumlib#4183 and quantumlib#4096.

@tanujkhattar

…#4748) Fixes quantumlib#4639, ref [tinyurl.com/clifford-simulators-refactor](https://tinyurl.com/clifford-simulators-refactor) This change makes the Clifford simulators more consistent with other simulators. Rather than the gate having all the logic of how to update the simulator state, which seemed out-of-place and limited the ability to reuse in any new kinds of Clifford simulators, this PR moves all the logic to the simulators themselves. It also creates an ABC for Clifford simulator states, allowing reuse of the evolution logic in the base class, such that the subclasses just have to implement the specific gate applicators. Note I *tried* doing this via a new Clifford protocol as well ([link](https://github.com/quantumlib/Cirq/compare/master...daxfohl:clifford3?expand=1)) as we originally discussed, and it works but I didn't like the result. The protocol ended up just duplicating all the information of the gate, in a weird structure, and felt like an extra, unnecessary, hacky wrapper around just using the gate itself. So I prefer the approach in this PR that just uses the gate instances directly, though I'm open to suggestion. @tanujkhattar @viathor (cc @ybc1991)

@daxfohl

Add initial Clifford Gate with multiple qubits. Compared with SingleQubitCliffordGate, it has fewer functionalities since we cannot enumerate all of them with PauliGates and several special single qubit properties like Bloch rotation no longer exist. Anyway, it provides several basic interactions: 1. It uses Clifford tableau as underlying data representation (different from the state representation). 2. It can be constructed from a tableau or list of operations (`_has_stabilizer_effect_` only). All Clifford gates can be built through \{S, H, CNOT\}, so we can construct any Clifford Gate from the list of operations. We just cannot pre-define it. 3. Decomposing into several basic operations. 4. Get unitary matrix through decomposing (we cannot do this in a reverse way from unitary to Clifford gate :( ). 5. Know how to interact with ActOnCliffordTableauArgs, i.e. it should be able to use with CliffordTableau simulator (Looks like we don't have that in cirq yet? @daxfohl will add that? see quantumlib#4639 and quantumlib#4748.). This PR is part of efforts for quantumlib#3639. Context: this PR doesn't introduce any new algorithms but the key methods are already implemented in quantumlib#4183 and quantumlib#4096.

daxfohl added the kind/design-issue A conversation around design label Nov 8, 2021

tanujkhattar added the triage/discuss Needs decision / discussion, bring these up during Cirq Cynque label Nov 10, 2021

daxfohl mentioned this issue Nov 12, 2021

Clifford-specific protocols #4676

Closed

viathor added area/clifford-group area/protocols labels Nov 17, 2021

daxfohl mentioned this issue Dec 13, 2021

Fix act-on specialization for all the Clifford simulators #4748

Merged

BichengYing mentioned this issue Jan 2, 2022

Multiple Qubits Clifford Gate #4791

Merged

tanujkhattar assigned viathor Jan 5, 2022

CirqBot closed this as completed in #4748 Jan 19, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clifford-specific protocols #4639

Clifford-specific protocols #4639

daxfohl commented Nov 8, 2021

daxfohl commented Nov 16, 2021 •

edited

Loading

tanujkhattar commented Nov 17, 2021

daxfohl commented Nov 20, 2021 •

edited

Loading

tanujkhattar commented Jan 5, 2022

Clifford-specific protocols #4639

Clifford-specific protocols #4639

Comments

daxfohl commented Nov 8, 2021

daxfohl commented Nov 16, 2021 • edited Loading

tanujkhattar commented Nov 17, 2021

daxfohl commented Nov 20, 2021 • edited Loading

tanujkhattar commented Jan 5, 2022

daxfohl commented Nov 16, 2021 •

edited

Loading

daxfohl commented Nov 20, 2021 •

edited

Loading