feat: pg-optimise - #1943
Conversation
cqc-alec
left a comment
There was a problem hiding this comment.
Looks good! Just a few comments and queries.
| tableaux. | ||
| Consider running `CanonicalFormPass` before either optimisation pass so that |
There was a problem hiding this comment.
| tableaux. | |
| Consider running `CanonicalFormPass` before either optimisation pass so that | |
| tableaux. | |
| Consider running `CanonicalFormPass` before either optimisation pass so that |
|
|
||
| ## Passes | ||
|
|
||
| - `GroupCommutingOpsPass` |
There was a problem hiding this comment.
I think we should try to be consistent about using noun phrases or verb phrases in pass names. Unfortunately tket2 is already inconsistent, so not sure what to suggest!
| /// The strings must use opposite encodings: one must have been packed with | ||
| /// `z_first` set to `true`, and the other with it set to `false`. |
There was a problem hiding this comment.
This seems like a weird condition. Is there a good reason for it? Can we not just settle on one convention (either X or Z first), and have this function handle it?
| z_first, | ||
| } | ||
| } | ||
| fn flip_to_zx(&mut self) { |
There was a problem hiding this comment.
Would coerce_to_zx be a better name? Since it might already be Z-first? (And in that case, should we short-circuit the manipulation?)
| let p0 = vec![Pauli::X, Pauli::I, Pauli::Z]; | ||
| let p1 = vec![Pauli::X, Pauli::I, Pauli::Z]; |
There was a problem hiding this comment.
These are the same, is that intentional?
| data: RotationData::new(vec![Pauli::X, Pauli::I], 0.4), | ||
| }); | ||
| let merged_pg = rotation_merging(&pg); | ||
| assert_eq!(merged_pg.get_ops().len(), 2); |
| let merged_pg = rotation_merging(&pg); | ||
|
|
||
| assert_eq!(merged_pg, pg); | ||
| assert!(compare_unitaries_via_tk(&pg, &merged_pg)); |
There was a problem hiding this comment.
This is redundant given the assertion above.
This PR introduces two passes:
GroupCommutingOpsPassandRotationMergingPass. See the README for details.