Skip to content

Conversation

@pedrorrivero
Copy link
Member

Summary

Adds new compute_uncompute function to automatically implement this strategy in any given input circuit (i.e. $U \rightarrow U^\dagger U$).

Details and comments

  • This is a utility function to avoid building these (well-known) circuits manually in present and upcoming notebooks.
  • Needed for the Utility Scaling notebook, demoed at IBM Quantum Practitioner's Forum 2023.

@pedrorrivero pedrorrivero added feature New feature request PL-2 Priority level 2/5 → Medium-high labels Feb 24, 2024
@pedrorrivero pedrorrivero self-assigned this Feb 24, 2024
@coveralls
Copy link

Pull Request Test Coverage Report for Build 8032164131

Details

  • 0 of 15 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 100.0%

Totals Coverage Status
Change from base Build 8031993973: 0.0%
Covered Lines: 19
Relevant Lines: 19

💛 - Coveralls

@pedrorrivero pedrorrivero changed the title feat(circuits): add compute_uncompute function feat(circuits): add compute_uncompute function Feb 24, 2024
@miamico
Copy link
Contributor

miamico commented Feb 26, 2024

I'm a little bit unsure about this. Let's have some discussion about pros and cons. My feeling is that if we do this for every single small function we'll end up with a huge baggage of tests.

Separate issue to clarify, if the corresponding notebook ends up on the learning platform, how are these functions retrieved?

@pedrorrivero
Copy link
Member Author

pedrorrivero commented Feb 26, 2024

Thanks @miamico

Yeah, this function started being significantly larger because it was applied to specific circuits but I ended up narrowing it down a lot in clean up. At this point I think we could/should add it to the notebook directly. Nonetheless, I'd still like to keep the construct in the available tooling for ease of reference in the future.

I think it is also a great simple example for the team on how to write tests. But let's talk offline if you want.

To retrieve this function (not sure exactly what you mean) you would do

from quantum_enablement.circuits import compute_uncompute

Copy link
Contributor

@miamico miamico left a comment

Choose a reason for hiding this comment

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

Looks good!

@miamico
Copy link
Contributor

miamico commented Mar 15, 2024

Thanks @miamico

Yeah, this function started being significantly larger because it was applied to specific circuits but I ended up narrowing it down a lot in clean up. At this point I think we could/should add it to the notebook directly. Nonetheless, I'd still like to keep the construct in the available tooling for ease of reference in the future.

I think it is also a great simple example for the team on how to write tests. But let's talk offline if you want.

To retrieve this function (not sure exactly what you mean) you would do

from quantum_enablement.circuits import compute_uncompute

I agree that the testing framework is hashed out nicely for this function and it is worth to keep the example around for reference. What I meant by "retrieve" is that when we run a notebook on the learning platform, does that notebook have access to the quantum_enablement repo?

@pedrorrivero
Copy link
Member Author

What I meant by "retrieve" is that when we run a notebook on the learning platform, does that notebook have access to the quantum_enablement repo?

Not yet, but it could be configured if we needed to and got approval. Great point!

@pedrorrivero pedrorrivero merged commit 35ab59f into main Mar 26, 2024
@pedrorrivero pedrorrivero deleted the compute-uncompute branch March 26, 2024 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New feature request PL-2 Priority level 2/5 → Medium-high

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants