Address executor and observable incompatibility

[bdg221]

Description

Fixes #2449

This PR address code changes in the Executor and Pauli classes to account for when an Observable is passed to an executor along with a circuit that already has a measurement on a qubit effected by the Observable.

Also, I removed a check in the Executor class, with the assumption the user is passing a valid executor if an observable is used.

Furthermore, the docs for the Executor and Observable have been updated with the annotation/typehinting requirement.

Finally, additional unit testing has been added to ensure that incompatible Executors and Observables are caught and an appropriate message is given to the user.

---

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.

• I added unit tests for new code.
• I used type hints in function signatures.
• I used Google-style docstrings for functions.
• I updated the documentation where relevant.

[bdg221]

I believe there are additional unit tests that need to be created to ensure that we cover as many scenarios as possible. This is especially true when we assume the user has defined a compatible executor when passing an observable.

I plan to discuss this in more detail with @natestemen to ensure appropriate test coverage.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.70%. Comparing base (6f912f6) to head (dc32389).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2514      +/-   ##
==========================================
- Coverage   98.71%   98.70%   -0.01%     
==========================================
  Files          89       90       +1     
  Lines        4131     4178      +47     
==========================================
+ Hits         4078     4124      +46     
- Misses         53       54       +1     

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

[bdg221]

@natestemen @cosenal I ran into a bit of an issue and I was curious how you think I should proceed. I added logic into the executor that will check the scenario where the executor does not have a return type specified and an observable is not passed. In this scenario we assume that the return type is float, therefore I am checking the circuits to make sure that there is a measurement included, if not I check if the return type was passed in (error messaging telling the user to include measurements in their circuit since they meant for it to return a float) or not (error message saying to use type hinting and if meant to return a float then add measurements.)

I believe this is what we want, however I found that we have over 200 tests that fail when the code is implemented. The executors in the tests that fail do not use type hinting and also do not include measurement gates (since typically a simple float is return like the length of the circuit or a random number.)

I can certainly go through and clean those up, however I am wondering if I should break that out to a new issue/PR because it is a bit involved.

We could also let the error come from the backend, however those messages may vary. We also cannot mention using type hinting with this option. Examples of some error messages from cirq and qiskit:
Circuit has no measurements to sample.
No counts for experiment

[bdg221]

It is line 192 to 204 that is causing the tests to fail.

[bdg221]

@natestemen @cosenal With this latest update, I am only checking now for obvious incompatibility. This means that if a user does use type hinting and does/does not include an observable it will throw errors in the following scenarios:

FloatLike should NOT have an observable
DensityMatrixLike MUST have an observable
MeasurementResultLike MUST have an observable

When the return type is MeasurementResultLike, we use the observable to add measurement gates to the circuit before call self.run(). Previously, if the return type was not specified this would result in an error from the backend because the circuit would not have measurements. However, now I added a test if self.run() fails to see if there is an observable and if so to add the measurement(s) to the circuit(s) and try self.run() again.

After calling self.run() successfully, we normally parse the results. FloatLike grabs np.real_if_close(), DensityMatrixLike uses the observable._expectation_from_density_matrix(), and MeasurementResultLike uses the observable._expectation_from_measurements(). While previously the code was looking self._executor_return_type, I am also now using the return type of the first object in the sequence returned by self.run().

I added tests that check the obviously bad scenarios when type hinting is used. Also, I compare the results of typed versus non-typed to make that if we assume the user does things correctly without type hinting that they get the correct answer.