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

Ensure that cirq.decompose traverses the yielded OP-TREE in dfs ordering #6117

Merged
merged 3 commits into from Jun 2, 2023

Conversation

tanujkhattar
Copy link
Collaborator

@tanujkhattar tanujkhattar commented Jun 1, 2023

This is a follow-up of #6116

The goal is to make sure that if a gate or operation has a _decompose_ defined such that operations are yielded one by one (i.e. the _decompose_() is a generator); then cirq.decompose(op) protocol should recursively decompose the yielded operations one by one.

This guarantee ensures that, if a user allocates / deallocates new qubits as part of the _decompose_ protocol; then all operations yielded between an allocation / deallocation request are recursively decomposed in order after the initial allocation request and before the deallocation request.

See the added test using mocks for more details.

Note that the default recommendation to users would be to use a SimpleQubitManager so they do not need to worry about this ordering. The guarantees here are brittle and depend largely on assuming that the user is doing the right thing; but this best effort implementation gets us closer to "doing the right thing" for the user with minimal changes to existing code.

cc @95-martin-orion @NoureldinYosri

Part of #6040

Copy link
Collaborator

@NoureldinYosri NoureldinYosri left a comment

Choose a reason for hiding this comment

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

overall LGTM. only the stub is an issue for me.

class RecursiveDecompose(cirq.Gate):
def __init__(self, recurse: bool = True, mock_qm: Optional[mock.Mock] = None):
self.recurse = recurse
self.mock_qm = mock.Mock() if mock_qm is None else mock_qm
Copy link
Collaborator

Choose a reason for hiding this comment

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

I see few places in Cirq where stubbing is used, lets not normalize that. Stubs can go horribly wrong => tests that are smoke tests, change detectors or worse tests that pass ragardless of the change.

lets do the test in a better way.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In this specific case, I think its okay to use stubs since we want to test the ordering in which cirq.decompose will traverse the yielded OP-TREE and this test asserts that specifically. I don't care about the behavior of a Qubit Manager in this test -- it will become relevant when we add a qubit manager and that would be the time to add an integration test.

I could modify the test that asserts the traversal order via some other mechanism (eg: keep a global counter and append items to a list whenever the qalloc / qfree statements are executed) but the mock is essentially doing the same thing so I don't see a reason to replace it with some other equivalent mechanism.

While I generally appreciate the concern for not overusing mocks to write tests, I think the use here is well justified. I'll be curious to hear any alternative suggestions you have in mind for rewriting the test though.

Copy link
Collaborator

@95-martin-orion 95-martin-orion left a comment

Choose a reason for hiding this comment

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

Approved based on review by @NoureldinYosri.

@NoureldinYosri NoureldinYosri enabled auto-merge (squash) June 2, 2023 21:26
@NoureldinYosri NoureldinYosri merged commit 99e8a13 into quantumlib:master Jun 2, 2023
36 checks passed
navaro1 pushed a commit to navaro1/Cirq that referenced this pull request Jun 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants