fixes #11393 sampled_expectation_value returning incorrect results for complex coefficients (gave 0.0 rather than 1j)

[Yosef-Bunick]

fixes #11393
partially fixes #16443
Root cause: two Rust functions computed Complex64 but returned Ok(.re).
PR #11471 got half of it,
they got sampled_expval_complex (.re → Ok)
but missed the sampled_expval_sparse_observable (.re → Ok)
also changed the "bit_array.py dtype + note" and added a few tests

AI/LLM disclosure

• I used the following tool to generate or modify code: ABE_v4 (personal custom AI engine)

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the following people are relevant to this code:

• @Qiskit/terra-core
• @ajavadia
• @levbishop
• @t-imamichi

[CLAassistant]

All committers have signed the CLA.

[Yosef-Bunick]

Fixes #11393

[mergify]

queue

☑️ Command disallowed due to command restrictions in the Mergify configuration.

Details

• sender-permission >= write

[ShellyGarion]

@Yosef-Bunick - Thank you for your contribution to Qiskit!
Could you please clarify whether this PR was authored purely using AI tools, or if you have reviewed and validated the changes yourself? We ask contributors to follow the guidelines on the use of AI tools, as described here: Qiskit Contribution Guidelines – Use of AI tools.
Please also note that issues labeled “good first issue” are primarily intended to support learning and development for human contributors and not AI tools.
Additionally, if this PR builds upon work by another contributor (e.g., #11471), could you please ensure they are properly credited, for example by adding them as a co-author?

[Yosef-Bunick]

@ShellyGarion
Yes I've read and reviewed the whole thing, and tried backtracking the issue.
The main issue with the first pull was that they tried changing it to complex64 formatting,
but they didn't change it on the return out.re->out and in python the equivalency is complex128.
If you would like me to add them as a coauthor, please advise how to add zeb33n.
If this one is good, I will try a harder one.

[ShellyGarion]

@ShellyGarion Yes I've read and reviewed the whole thing, and tried backtracking the issue. The main issue with the first pull was that they tried changing it to complex64 formatting, but they didn't change it on the return out.re->out and in python the equivalency is complex128. If you would like me to add them as a coauthor, please advise how to add zeb33n. If this one is good, I will try a harder one.

If possible, you can add them by a git commit co-authored-by.
If this doesn't work, just mention it in the PR decryption above.

[Yosef-Bunick]

@ShellyGarion Yes I've read and reviewed the whole thing, and tried backtracking the issue. The main issue with the first pull was that they tried changing it to complex64 formatting, but they didn't change it on the return out.re->out and in python the equivalency is complex128. If you would like me to add them as a coauthor, please advise how to add zeb33n. If this one is good, I will try a harder one.

If possible, you can add them by a git commit co-authored-by. If this doesn't work, just mention it in the PR decryption above.

@ShellyGarion
Added test and added co-authored by zeb33n.
Lmk if it looks right.

[ShellyGarion]

it seems that there are formatting errors and tests failures. please check this.

[Yosef-Bunick]

@ShellyGarion
should be good to go, fixed the -1 error, (mistake in test)
changed the lint error, ok(result?)->result

@ihincks changed to arr->np.real_if_close(arr) and
[np.complex128]:->[np.float64 | np.complex128]:
to support it.

I got All passing on tests localy

[Cryoris]

I'm wondering if we want to expose a tolerance to cutoff the imaginary part, np.real_if_close does support this. We can leave this as a follow up though.

If the test concerns I left are addressed this LGTM.

[Yosef-Bunick]

I'm wondering if we want to expose a tolerance to cutoff the imaginary part, np.real_if_close does support this. We can leave this as a follow up though.

If the test concerns I left are addressed this LGTM.

@Cryoris
prob more ideal to put 'non default tol' in separate pull in case the 'non default tol' isn't appealing and can be reverted easily.

fixed the docstrings that didn't match what was actually being tested,
added assertNotIsInstance(result, complex) guards on both real-coefficient paths so a missing np.real_if_close gets caught.

should be ready to push, passed the lint, black, and tests localy.

[Yosef-Bunick]

I'm wondering if we want to expose a tolerance to cutoff the imaginary part, np.real_if_close does support this. We can leave this as a follow up though.

reference for separate pull
{
details for tol fix reference, might need different hookup depending on where you want it hooked up.
qiskit/result/sampled_expval.py: approximately line 40 "tol: float = 100," 75 "tol=tol", 90 "tol=tol"
qiskit/primitives/containers/bit_array.py: approximately line 616 "tol: float = 100," 650 "tol=tol", 654 "tol=tol"
and add test.
}

[Cryoris]

@Yosef-Bunick The PR title is getting out of hand, please just use a short descriptive title of what this is fixing.

[Yosef-Bunick]

Now, this pull only fixes sampled_expectation_value returning incorrect results for complex coefficients.
Moved bit_array.py to a separate pull request since they are independent.