feature: count circuit operation on circuit or given qubits

[skushagra]

*Issue #1235

Description of changes:
I have added a count_instruction functions that gives you count of an instrcution on a circuit. I have added test cases for the required flow.

Features

• Count instructions by operator type.
• Optional filtering by:
  • Operator name, operator class, or operator instance.
  • Qubits involved in an instruction.
  • Moment types (GATE, GATE_NOISE, MEASURE etc.).
• Supports multi-qubit filtering via:
  • QubitMatch.ANY — instruction on any specified qubit.
  • QubitMatch.ALL — instruction on all specified qubits.
• When both operator and qubit filters are provided, instructions must satisfy both filters (AND).

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• I have read the CONTRIBUTING doc
• I used the PR title format described in CONTRIBUTING
• I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[skushagra]

I did not understand much around what can we do for calculating density of operations. I would need more clarification on how should we exactly define this density, and since there can be multiple ways with respect to which density can be calculated like, operations per layer, per qubit etc.

Hence I extracted this into a seprate helper file to prevent bloating the Circuit class. Perhaps more clarification on this would help me to add such a features.

[aniksd-braket]

@skushagra could you also make sure to resolve all comments for the next updated CR

[aniksd-braket]

@skushagra are you still working on this?

[skushagra]

Yes I am, will resolve these comments in a bit

[skushagra]

@aniksd-braket fixed the pending comments, please have a look and let me know if anything else is needed

[aniksd-braket]

This looks good, getting closer to the final product. I am assuming you used AI for creating tests? some of them seem repetitive/unnecessary. can you trim it down and/or consolidate them?

[aniksd-braket]

@skushagra just a bump on this

[skushagra]

Yes, I'll consolidate and remove the unnecessary tests.

[skushagra]

Hi @aniksd-braket

I have updated the test file to keep only those that I feel were important and those that were discussed in your review. Let me know if there are any other instances that you'd like to capture here, will add them accordingly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (2916f20) to head (d0e510c).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1278   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          170       170           
  Lines        11214     11250   +36     
  Branches      1450      1457    +7     
=========================================
+ Hits         11214     11250   +36     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[skushagra]

Fixed all codecov, linter and formatter issues

[aniksd-braket]

Thank you for your effort @skushagra! One last request, could add some checks to ensure that errors are raised if an invalid qubit or operator name is passed in as an argument. For eg: a qubit that is not part of the circuit or a operator that is not defined. If the qubit is part of the circuit but has no gates on it, it should just return an empty counter. Similarly, if the operation is a valid braket operation but does not exist in the circuit it should return an empty counter

[skushagra]

Sure, will add this

[skushagra]

@aniksd-braket

One question, how should I validate the operator names, qubit range is simple enough to check, but for operators etc. should i use src/braket/circuits/translations.py or something like Operator.__subclasses__() to find all at runtime?

[aniksd-braket]

@skushagra yes translations should be a good reference

[skushagra]

what about when users want to count some custom implementaiton, I think that will be a common usecase?