Skip to content
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

Deprecate the condition attribute and related functionality #13223

Merged
merged 13 commits into from
Oct 31, 2024

Conversation

mtreinish
Copy link
Member

Summary

This commit deprecates the Instruction.condition and c_if() method for removal in 2.0. This functionality has been superseded by the more sophisiticated IfElseOp for some time now. Removing the condition property will simplify the Qiskit data model as it is implemented in a kind of ad-hoc manner that adds additional overhead to manually check it in many places.

For the unittest modifications the deprecation warning for the .condtion getter is suppressed for the entire suite because this gets triggered internally by the transpiler and a lot of other places, including from rust code as until it is removed we need to use it to check that piece of the data model.

Details and comments

Fixes #9556

This commit deprecates the Instruction.condition and c_if() method for
removal in 2.0. This functionality has been superseded by the more
sophisiticated `IfElseOp` for some time now. Removing the condition
property will simplify the Qiskit data model as it is implemented in
a kind of ad-hoc manner that adds additional overhead to manually check
it in many places.

For the unittest modifications the deprecation warning for the .condtion
getter is suppressed for the entire suite because this gets triggered
internally by the transpiler and a lot of other places, including from
rust code as until it is removed we need to use it to check that piece
of the data model.

Fixes Qiskit#9556
@mtreinish mtreinish added priority: high Changelog: Deprecation Include in "Deprecated" section of changelog mod: circuit Related to the core of the `QuantumCircuit` class or the circuit library labels Sep 25, 2024
@mtreinish mtreinish added this to the 1.3.0 milestone Sep 25, 2024
@qiskit-bot
Copy link
Collaborator

One or more of the following people are relevant to this code:

  • @enavarro51
  • @Cryoris
  • @Qiskit/terra-core
  • @ajavadia
  • @levbishop
  • @mtreinish
  • @nkanazawa1989
  • @t-imamichi

@coveralls
Copy link

coveralls commented Sep 26, 2024

Pull Request Test Coverage Report for Build 11599100254

Warning: 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

  • 81 of 83 (97.59%) changed or added relevant lines in 29 files are covered.
  • 40 unchanged lines in 6 files lost coverage.
  • Overall coverage increased (+0.02%) to 88.73%

Changes Missing Coverage Covered Lines Changed/Added Lines %
qiskit/qpy/binary_io/circuits.py 4 6 66.67%
Files with Coverage Reduction New Missed Lines %
crates/accelerate/src/unitary_synthesis.rs 1 92.2%
crates/qasm2/src/lex.rs 2 93.23%
crates/qasm2/src/parse.rs 6 97.62%
qiskit/result/mitigation/utils.py 8 89.74%
qiskit/result/mitigation/correlated_readout_mitigator.py 10 89.69%
qiskit/result/mitigation/local_readout_mitigator.py 13 90.15%
Totals Coverage Status
Change from base Build 11598008270: 0.02%
Covered Lines: 75638
Relevant Lines: 85245

💛 - Coveralls

Copy link
Contributor

@ElePT ElePT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, this PR is long. I didn't get to review all tests but I left a few minor suggestions that I saw in the source code/reno.

qiskit/circuit/instruction.py Outdated Show resolved Hide resolved
Co-authored-by: Elena Peña Tapia <[email protected]>
Copy link
Contributor

@ElePT ElePT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! I just found a couple of deprecation warning assertions that I think would be good to clarify (maybe adding a comment explaining how they relate to this deprecation like you did in other cases).

Comment on lines +225 to +226
with self.assertWarns(DeprecationWarning):
self.assertTrue(Operator(circuit).equiv(Operator(result)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is the warning triggered here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Operator(circuit) runs circuit.to_instruction() which checks for condition iirc.

Comment on lines +29 to +30
with self.assertWarns(DeprecationWarning):
new_qc = ResetAfterMeasureSimplification()(qc)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think this class raising a deprecation warning is a desired outcome (I'm not sure why it's raised)? Maybe the stack level of the warning isn't correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The testing harness will trigger if the warning is raised at any stack level even if it's not user code. This is to let us catch internal usage of deprecated functionality in our dependencies. In this case the ResetAfterMeasureSimplification pass only works with c_if and condition. so the warning is coming from inside the pass.

This does raise a good question about what we want to do with that pass, we probably should convert it to an if statement internally. I don't remember what I was thinking when I opened this 2 weeks ago, probably that I would do it in a followup PR. But it would be better if I do it here instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I went to do this I remember why I didn't change it. I decided at the time that leaving the pass using c_if for 1.x made the most sense as using an IfElseOp instead could have been viewed as a potential change in behavior and wanted to save that for 2.0.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with not changing the behavior yet. I brought this up thinking about downstream packages and how they sometimes get "flooded" by our deprecation warnings even if they aren't actionable. But I guess it's on them to set the stack level they want to see in their tests.

This commit fixes some places in the code where we were using the
deprecated functionality where it needed a path to persist the behavior
or where the deprecation warning became a performance bottleneck. The
code is updated accordingly and to catch issues like this in the future
the warning filters are adjusted to be more selective.
@mtreinish mtreinish requested a review from ElePT October 7, 2024 21:26
@ElePT ElePT self-assigned this Oct 21, 2024
Copy link
Contributor

@ElePT ElePT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +29 to +30
with self.assertWarns(DeprecationWarning):
new_qc = ResetAfterMeasureSimplification()(qc)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with not changing the behavior yet. I brought this up thinking about downstream packages and how they sometimes get "flooded" by our deprecation warnings even if they aren't actionable. But I guess it's on them to set the stack level they want to see in their tests.

@ElePT ElePT added this pull request to the merge queue Oct 31, 2024
Merged via the queue into Qiskit:main with commit c6efb76 Oct 31, 2024
17 checks passed
@mtreinish mtreinish deleted the deprecate-condition_cif branch October 31, 2024 14:56
Comment on lines +13 to +29
qc = QuantumCircuit(2, 2)
qc.h(0)
qc.x(0).c_if(0, 1)
qc.z(1.c_if(1, 0)
qc.measure(0, 0)
qc.measure(1, 1)

can be rewritten as::

qc = QuantumCircuit(2, 2)
qc.h(0)
with expected.if_test((expected.clbits[0], True)):
qc.x(0)
with expected.if_test((expected.clbits[1], False)):
qc.z(1)
qc.measure(0, 0)
qc.measure(1, 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just started addressing this deprecation warning and noticed some issues here. I think it should be qc.z(1) (missing parenthesis). Also, I think expected should be qc?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: Deprecation Include in "Deprecated" section of changelog mod: circuit Related to the core of the `QuantumCircuit` class or the circuit library priority: high
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deprecate Instruction.condition in favor of IfElseOp
5 participants