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

LRE Executors #2499

Merged
merged 16 commits into from
Oct 1, 2024
Merged

LRE Executors #2499

merged 16 commits into from
Oct 1, 2024

Conversation

purva-thakre
Copy link
Contributor

@purva-thakre purva-thakre commented Sep 11, 2024

Description

Fixes #2370

List of todos:

  • Docstrings
  • Additional unit tests

License

  • I license this contribution under the terms of the GNU GPL, version 3 and grant Unitary Fund the right to provide additional permissions as described in section 7 of the GNU GPL, version 3.

Before opening the PR, please ensure you have completed the following where appropriate.

Copy link

codecov bot commented Sep 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.72%. Comparing base (1a3705c) to head (21aeb4d).
Report is 6 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2499   +/-   ##
=======================================
  Coverage   98.71%   98.72%           
=======================================
  Files          89       90    +1     
  Lines        4131     4156   +25     
=======================================
+ Hits         4078     4103   +25     
  Misses         53       53           

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

@purva-thakre purva-thakre force-pushed the lre_Executor branch 2 times, most recently from e328b9d to 52e0812 Compare September 11, 2024 19:10
@purva-thakre purva-thakre marked this pull request as ready for review September 13, 2024 09:41
@purva-thakre
Copy link
Contributor Author

purva-thakre commented Sep 13, 2024

This test does not fail locally: https://github.com/unitaryfund/mitiq/actions/runs/10847148259/job/30101612145?pr=2499#step:6:4556

Will dig into this.

Copy link
Member

@natestemen natestemen left a comment

Choose a reason for hiding this comment

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

Nice work Purva! All your hard work makes this a nice and simple PR :)

Maybe we can do some debugging as to the num_chunks issue in tomorrows coding session.

mitiq/lre/lre.py Outdated Show resolved Hide resolved
mitiq/lre/lre.py Outdated
Comment on lines 27 to 29
folding_method: Callable[
[Union[Any], float], Union[Any]
] = fold_gates_at_random,
Copy link
Member

Choose a reason for hiding this comment

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

Let's follow what happens in ZNE here for consistency.

scale_noise: Callable[[QPROGRAM, float], QPROGRAM] = fold_gates_at_random, # type: ignore [has-type]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't use the num_to_average param in LRE.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I'm missing how num_to_average is related here. I'm just suggesting we typehint the folding method differently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's weird. I was viewing this suggestion locally in VS code. I interpreted 'follow what happens in ZNE for consistency' as use the typehint as well as the additional param.

image

Copy link
Member

Choose a reason for hiding this comment

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

Have you modified code above these lines? If so then it will probably change the location of the suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I hadn't modified anything in ZNE which is why it's weird that when you linked L70 in zne.py, L71 also showed up.

The location of the suggestion was not changed.

mitiq/lre/lre.py Outdated Show resolved Hide resolved
mitiq/lre/tests/test_lre.py Outdated Show resolved Hide resolved
mitiq/lre/tests/test_lre.py Outdated Show resolved Hide resolved
Copy link
Contributor

@cosenal cosenal left a comment

Choose a reason for hiding this comment

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

I left two comments, not blockers.

mitiq/lre/lre.py Outdated Show resolved Hide resolved
"""Verify LRE decorators work as expected."""

@lre_decorator(degree=2, fold_multiplier=2)
def execute(circuit, noise_level=0.025):
Copy link
Contributor

Choose a reason for hiding this comment

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

Something more in the spirit of unit tests (and more future-proof) would be a test that only checks whether the correct functions are called, and doesn't actually run the circuit through the simulator. Here you are testing lots of things at the same time (including a Google's simulator), all of which could go wrong without giving much insights on the unit you are testing here, which is the behaviour of the new decorator.

Copy link
Contributor Author

@purva-thakre purva-thakre Sep 27, 2024

Choose a reason for hiding this comment

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

@cosenal @natestemen Are either of you available for a quick call on Friday (excluding the community call)? I have been unsuccessful in trying to write a unit test that utilizes mock objects.

It's unclear to me what needs to be a mock object and what must have a pre-defined value.

ideal_val = execute(test_cirq * 200, noise_level=0)
assert abs(ideal_val - noisy_val) > 0
lre_exp_val = execute_with_lre(
test_cirq * 200, execute, degree=2, fold_multiplier=2, num_chunks=5
Copy link
Contributor

Choose a reason for hiding this comment

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

I misled you by not creating a variable for test_cirq * 200 in y'day live coding*, but we do want one in the pull request.

*As @natestemen was bugging me about while I tried to hack things around as quick as possible 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am going to use the mock testing module for this. As Nate noticed yesterday, test_cirq * 200 will increase the time taken by unit tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Discussed with Nate and Alessandro to skip this unit for when we get to #2512 in the future.

The code block that misbehaves when we have really large circuits is in one of the inference functions.

except RuntimeWarning: # pragma: no cover
# taken from https://stackoverflow.com/a/19317237
warnings.warn( # pragma: no cover
"To account for overflow error, required determinant of "
+ "large sample matrix is calculated through "
+ "`np.linalg.slogdet`."
)
sign, logdet = np.linalg.slogdet( # pragma: no cover
input_sample_matrix
)
det = sign * np.exp(logdet) # pragma: no cover
if np.isinf(det):
raise ValueError( # pragma: no cover
"Determinant of sample matrix cannot be calculated as "
+ "the matrix is too large. Consider chunking your"
+ " input circuit. "
)

@purva-thakre
Copy link
Contributor Author

purva-thakre commented Sep 27, 2024

I don't know why some of the tests are failing right now. Will rerun them in a couple of hours.

Copy link
Member

@natestemen natestemen left a comment

Choose a reason for hiding this comment

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

A few minor changes requested, but looking good once those are addressed.

How long does it take to run the tests in test_lre.py?

mitiq/lre/lre.py Outdated Show resolved Hide resolved
mitiq/lre/tests/test_lre.py Outdated Show resolved Hide resolved
mitiq/lre/tests/test_lre.py Outdated Show resolved Hide resolved
mitiq/lre/lre.py Outdated Show resolved Hide resolved
@purva-thakre
Copy link
Contributor Author

How long does it take to run the tests in test_lre.py?

I used pytest --durations=0 test_lre.py in mitiq/mitiq/lre/tests to get the following:

image

Chunking test where it is not expected to fail takes the longest.

https://stackoverflow.com/a/55095253

@purva-thakre purva-thakre merged commit 411e234 into main Oct 1, 2024
17 of 18 checks passed
@purva-thakre purva-thakre deleted the lre_Executor branch October 1, 2024 19:53
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.

Executors for LRE
3 participants