-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Add rust representation for the u1, u2, and u3 gates #12572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
One or more of the following people are relevant to this code:
|
dce2b20
to
afad78d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM, just two questions from my side 🙂
@@ -374,6 +382,23 @@ impl Operation for StandardGate { | |||
} | |||
_ => None, | |||
}, | |||
Self::U1Gate => match params[0] { | |||
Param::Float(val) => Some(aview2(&gate_matrix::u1_gate(val)).to_owned()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed that &gate_matrix::u1_gate(val)
is not dereferencing val
, while the other gate calls do: &gate_matrix::u2_gate(*phi, *lam)
, u3_gate(*theta, *phi, *lam)
. Was this intentional? (aha, it's because it's just a float, never mind).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference here is that the match is on params[0]
instead of params
. The val
is already an f64
and you can't dereference that, while for the other gates the angles have &f64
.
I haven't dug into the test failures yet, but I suspect it's more likely I screwed up something in the translation. The qasm3 failure at least is because there are no longer fixed object ids for the gates and I need to update the test to account for that (i.e. use a regex).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is a blocker for #12598 feel free to just rebase it on main and move ahead without this. I can reindex the gates in this PR without too much trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the test failures in: 65ff009 the optimize 1q gates decomposition failures were because the tests were doing:
gate.definition.global_phase = val
and that doesn't do anything to the gate object for a standard gate in rust. TBH, I have no idea what this test is trying to do but to fix it I just used a custom gate class instead of U1Gate
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So gate.definition.global_phase = val
is another of the "hidden forbidden moves", like dag_node.op.params[0]
. Do you think we should document it in the reno too? At a first glance people would probably not expect it to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it needs one, the definition was never really supposed to be mutable like this as it's an inherent attribute of a gate, changing it doesn't make much sense (for most things it doesn't get used either). This already wouldn't work with singletons as changing the global phase would affect every instance of the gate. I viewed this as test bug, because I have no idea what that test was trying to accomplish. But I can add a release note out of an abundance of caution if you think it's warranted here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm I think it would be nice to have it documented somewhere, but I am ok just keeping an eye on it, I don't think people refer to the release notes anywhere and I see how documenting every edge case can be a problem.
This commit adds the rust representation of the U1Gate, U2Gate, and U3Gate to the `StandardGates` enum in rust. Part of Qiskit#12566
Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
53fa181
to
65ff009
Compare
Pull Request Test Coverage Report for Build 9618403783Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build 9618804762Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation LGTM, I just had a couple of questions about the cases that triggered test failures.
@@ -102,7 +113,7 @@ def test_matrix(self): | |||
continue | |||
|
|||
with self.subTest(name=name): | |||
params = [pi] * standard_gate._num_params() | |||
params = [0.1] * standard_gate._num_params() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this change because math.pi
was triggering some of the test failures? I feel like it's commonly used for assigning parameter values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I thought I changed it back. While debugging I did this because one of the test failures was using 0.1 as the angle value and I wanted to rule that out as the cause of the failure (checking the matrix was also correct with 0.1). I can change it back to pi, it realistically doesn't matter too much though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd even expect 0.1 to be a better value for testing since for pi the matrices take on some special forms and 0.1 is more "irregular" in that sense 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I just wanted to make sure we were not ignoring pi.
@@ -374,6 +382,23 @@ impl Operation for StandardGate { | |||
} | |||
_ => None, | |||
}, | |||
Self::U1Gate => match params[0] { | |||
Param::Float(val) => Some(aview2(&gate_matrix::u1_gate(val)).to_owned()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So gate.definition.global_phase = val
is another of the "hidden forbidden moves", like dag_node.op.params[0]
. Do you think we should document it in the reno too? At a first glance people would probably not expect it to fail.
* Add rust representation for the u1, u2, and u3 gates This commit adds the rust representation of the U1Gate, U2Gate, and U3Gate to the `StandardGates` enum in rust. Part of Qiskit#12566 * Update crates/circuit/src/imports.rs Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> * Fix test failures * Fix pylint pedantry --------- Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
Summary
This commit adds the rust representation of the U1Gate, U2Gate, and U3Gate to the
StandardGates
enum in rust.Details and comments
Part of #12566