-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add AnnotatedOperation.params
and fix some control issues
#12752
Conversation
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 10113248178Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - 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.
This looks really great!
One thing I am confused about is the new ternary semantics of annotated
: with this PR it can be either False
, True
or None
. Would it have been possible to achieve the same result without introducing the None
value but by changing the default in the newly added control methods to annotated=True
?
Previously the semantics of annotated
was as follows: False
- means do not create an annotated gate, this was required for backward compatibility. True
- means introduce an annotated gate unless there is a friendlier gate available, e.g. x.control(1, annotated=True)
would produce a CX
-gate, not an annotated operation.
they contain unbound parameters. Previously, this raised an error, but | ||
now we create an :class:`.AnnotatedOperation` as placeholder. This |
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.
Maybe say something like: "Previously, this raised an error when such gates were added to the circuit, but ..."
Could you please also a test for reading/setting params for an annotated operation of an annotated operation of a gate? |
That would've been my preferred solution as well, but I thought the default argument cannot change in between classes derived from the same object. If that's allowed, then it would be the nicer solution 🙂 Edit: but the default value also changes with respect to the number of controls and whether the gate parameters are unbound... so we cannot really set it to |
Suppose we keep the default
In this way we do not change anything that used to work before, and obtain annotated operations for controlled parametric gates. Personally I prefer this slightly over the ternary semantics, but I am happy to change my opinion. |
The advantage of what you're describing is that we don't have to change the signature, which would be nice as it reduces the amount of required change. But this has two downsides:
In the
I'm not sure I fully understand: if I do |
Thanks @Cryoris. I am not against merging this PR in the current form, and as it fixes an important set of problems we should definitely include it in 1.2. However, let me try to describe again the two options which I think we have. First option (as I am proposing). We only have two values Second option (as you are proposing). We have three values After writing this down so explicitly, I actually start liking the second choice much better :). Especially if the default value is So, provided that we fully agree to go with the second option, the only thing I would like to ask you is to make the semantics of |
- use attribute error - more clearly state the new None arg in reno and Gate class
Option 2 it is then 🙂 I added more detailed explanations about the |
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 think the PR looks very good, just left a few minor wording suggestions.
f"Cannot set attribute ``params`` on the base operation {self.base_op}." | ||
) | ||
|
||
def validate_parameter(self, parameter: ParameterValueType) -> ParameterValueType: |
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.
Small question, would it be more coherent if we called it validate_param
? I am a bit on the fence, I tend to prefer full words but I find it strange that the other methods say params
and this one says parameter
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.
This is coming from Instruction.validate_parameter
, to have AnnotatedOperation
work as drop-in-replacement 🙂
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.
LGTM! I just added two comma-related minor suggestions. After they are applied I think the PR is ready to be merged.
Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
* AnnotatedOp.params support and Gate.control fix * add reno * lint * update reno * review comments - use attribute error - more clearly state the new None arg in reno and Gate class * review from Elena * Fix ``AttributeError`` test * lint * Apply suggestions from code review Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> --------- Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> (cherry picked from commit 1512535)
…12828) * AnnotatedOp.params support and Gate.control fix * add reno * lint * update reno * review comments - use attribute error - more clearly state the new None arg in reno and Gate class * review from Elena * Fix ``AttributeError`` test * lint * Apply suggestions from code review Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> --------- Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> (cherry picked from commit 1512535) Co-authored-by: Julien Gacon <gaconju@gmail.com>
…2752) * AnnotatedOp.params support and Gate.control fix * add reno * lint * update reno * review comments - use attribute error - more clearly state the new None arg in reno and Gate class * review from Elena * Fix ``AttributeError`` test * lint * Apply suggestions from code review Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> --------- Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
Summary
Adds support for
AnnotatedOperation.params
and, leveraging that, fixes some issues when controlling standard gates that are parameterized. Closes #10311, #10697 and #12135.Since this PR also changes
AnnotatedOperation
it's probably too large for a backport?Details and comments
AnnotatedOperation.params
is a proxy to tobase_op.params
, if it exists. If thebase_op
has noparams
, returns an empty list (as discussed with the team offline).annotated
argument inGate.control
now isNone
per default, which allows to set it toTrue
for gates that cannot be eagerly synthesized. A test for each gate that failed previously is added.S/Sdg
gates didn't returnCS/CSdg
gates for a single control, that's also been fixed.