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

OutcomeArray handling producing unexpected numpy types with numpy 2 #1677

Closed
ss2165 opened this issue Nov 14, 2024 · 2 comments · Fixed by #1713
Closed

OutcomeArray handling producing unexpected numpy types with numpy 2 #1677

ss2165 opened this issue Nov 14, 2024 · 2 comments · Fixed by #1713
Assignees
Labels
bug Something isn't working

Comments

@ss2165
Copy link
Member

ss2165 commented Nov 14, 2024

code:

from pytket.extensions.qiskit import AerBackend
from pytket import Circuit
print(AerBackend().run_circuit(Circuit(1).measure_all(), 10).get_counts())

Outputs:
With numpy 1.26.4:

Counter({(0,): 10})

With numpy 2.1.3:

Counter({(np.uint8(0),): np.int64(10)})
@CalMacCQ
Copy link
Contributor

CalMacCQ commented Dec 4, 2024

Minor comment.

I added a workaround to the quantum phase estimation example notebook -> https://docs.quantinuum.com/tket/user-guide/examples/algorithms_and_protocols/phase_estimation.html

See the the tuple_to_str function which avoids label clashing on the x-axis of the results plot. workaround added in CQCL/pytket-docs#410

@cqc-alec
Copy link
Collaborator

cqc-alec commented Dec 9, 2024

Actually we were producing the same types in numpy 1, but never noticed because they were rendered differently.

In numpy 1, repr(numpy.uint8(1)) is 1; in numpy 2 it is np.uint8(1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants