You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ValentinKlinger In our GitHub build workflow, we currently have this:
- name: Run tests# See: #6591 for re-enabling tests on Python v3.11run: pytest--ignore=computer_vision/cnn_classification.py--ignore=machine_learning/lstm/lstm_prediction.py--ignore=quantum/--ignore=project_euler/--ignore=scripts/validate_solutions.py--cov-report=term-missing:skip-covered--cov=. .
So we're aware that some files in quantum/ have failing tests. Apparently they're ignored for now because for a while qiskit was incompatible with Python 3.11 (#6591).
As for web_programming/instagram_crawler.py, I ran it on my own machine and figured out that the code is failing here:
extract_user_profile(scripts[4]) throws a JSONDecodeError, which is caught by the except, but the problem is that extract_user_profile(scripts[3]) throws a JSONDecodeErroras well. Since the script never catches this second error, the test fails.
The big problem with having these sorts of web scripts in this repo is that they're difficult to test and easily break if the website they access changes. However, I'm not sure why these tests are passing in pytest in our GitHub build.
changed the title [-]Fix failing: pytest quantum/bb84.py quantum/q_fourier_transform.py[/-][+]Fix failing: `pytest quantum/bb84.py quantum/q_fourier_transform.py`[/+]on Jun 25, 2023
I changed the title of this issue to reflect the work that remains:
Fix pytest quantum/bb84.py quantum/q_fourier_transform.py and remove the corresponding lines:
These tests used to pass as they are. I assume that changes made in our dependencies changed the generated key values. Please submit a pull request if you see how to fix the tests.
for quantum/bb84.py I observed that the key is generating is correct whereas the key (as outputs) provided in doctests are different.
@rohan472000 How did you confirm that the keys generated in main are correct? The algorithm relies heavily on random numbers, so I'm not sure how we'd confirm that the algorithm is implemented correctly without an external source.
These tests used to pass as they are. I assume that changes made in our dependencies changed the generated key values. Please submit a pull request if you see how to fix the tests.
@cclauss The problem is that I believe the contributor originally based the implementation on this Qiskit learning article, but that link is now broken. There's this newer link, but the implementation in this article is significantly different from the contributor's implementation in a few ways. I tried to check whether the current implementation at least matches
if__name__=="__main__":
print(f"The generated key is : {bb84(16, seed=0)}")
but the current implementation outright segfaults. I don't know if there's any way for us to confirm whether the original implementation was ever correct (unless one of us happens to be very familiar with Qiskit and quantum key distribution).
Edit: I found the original Qiskit article on the Wayback Machine (snapshot is from October 2022 and the implementation is from November 2022, so this is the closest version of the article). However, the implementation in this older article appears to be the same as the one in the current article, so I have no idea how the contributor originally came up with their implementation.
for quantum/bb84.py I observed that the key is generating is correct whereas the key (as outputs) provided in doctests are different.
@rohan472000 How did you confirm that the keys generated in main are correct? The algorithm relies heavily on random numbers, so I'm not sure how we'd confirm that the algorithm is implemented correctly without an external source.
I'm not confirming it, I was running it locally so I observed that, not sure how it was passing the doctest before.
With this doctest's output that u have provided in PR it will pass definitely as I had tried it also in local, but my question is how the previous outputs were passing correctly and why they r failing now??
This is a seed-based pseudorandom number generator that generates the same result when given the same seed. The problem was that a newer version of qiskit modified their algorithm so the expected result needs to reflect that change.
However, the implementation in this older article appears to be the same as the one in the current article, so I have no idea how the contributor originally came up with their implementation.
@tianyizheng02 The implementation here is based on a summer research I did before Qiskit textbook had their example up. It is completely equivalent in functionality, just organized differently. Does the segfault problem still exist? Nothing in the example itself allocated memory, so it would be something that changed in the dependencies.
@cclauss Sorry for the late response. I'm spread a little thin at the moment. I gather that the updated doctests fixed the problem?
The implementation here is based on a summer research I did before Qiskit textbook had their example up. It is completely equivalent in functionality, just organized differently. Does the segfault problem still exist? Nothing in the example itself allocated memory, so it would be something that changed in the dependencies.
The segfault problem still exists. My guess is that it could be due to the large circuit size causing memory issues (Qiskit avoids this in their example by using a list of single-qubit circuits rather than one n-qubit circuit), but I'm not familiar enough with Qiskit to know if this is plausible.
What hardware are you running this on? Please document the steps to reproduce. For extra credit, a GitHub Action that demonstrates the segfault. ;-)
should I raise a PR by changing its output???
I am no FFT guru but my hunch is that the 2500 * 4 dict is the correct answer.
It would be great to get more feedback before we change the expectations to fit the actual.
QFT is a probabilistic algorithm, the results will have some variability.
I can see that after running each time I'm getting new outputs. Yeah..Let's wait for more feedback.
changed the title [-]Fix failing: `pytest quantum/bb84.py quantum/q_fourier_transform.py`[/-][+]Fix failing: `pytest quantum/q_fourier_transform.py`[/+]on Jun 26, 2023
QFT is a probabilistic algorithm, the results will have some variability. I can see that after running each time I'm getting new outputs. Yeah..Let's wait for more feedback.
I confirm, each time new values. And there you need to make a correction in the code to run the tests. For example, execute is removed in new versions qiskit .
Here is the result of two test calls (q_fourier_transform.py):
Activity
tianyizheng02 commentedon Jun 13, 2023
@ValentinKlinger In our GitHub build workflow, we currently have this:
So we're aware that some files in
quantum/have failing tests. Apparently they're ignored for now because for a whileqiskitwas incompatible with Python 3.11 (#6591).As for
web_programming/instagram_crawler.py, I ran it on my own machine and figured out that the code is failing here:extract_user_profile(scripts[4])throws aJSONDecodeError, which is caught by theexcept, but the problem is thatextract_user_profile(scripts[3])throws aJSONDecodeErroras well. Since the script never catches this second error, the test fails.The big problem with having these sorts of web scripts in this repo is that they're difficult to test and easily break if the website they access changes. However, I'm not sure why these tests are passing in
pytestin our GitHub build.ValentinKlinger commentedon Jun 14, 2023
Okey, thank you, I can't try now because I had to reboot my computer for exams, I'll try when my exam's over.
GitHub Actions build: Add more tests
[-]Pytest give me "4 failed"[/-][+]Fix failing: pytest quantum/bb84.py quantum/q_fourier_transform.py[/+][-]Fix failing: pytest quantum/bb84.py quantum/q_fourier_transform.py[/-][+]Fix failing: `pytest quantum/bb84.py quantum/q_fourier_transform.py`[/+]cclauss commentedon Jun 25, 2023
Thanks for spotting this @ValentinKlinger
#8837 fixed two of the four failing tests.
I changed the title of this issue to reflect the work that remains:
Fix
pytest quantum/bb84.py quantum/q_fourier_transform.pyand remove the corresponding lines:Python/.github/workflows/build.yml
Lines 27 to 28 in 3bfa89d
cclauss commentedon Jun 25, 2023
@abhishekchak52, @KevinJoven11 would you be willing to look at these two failing tests?
rohan472000 commentedon Jun 25, 2023
@cclauss , for
quantum/bb84.pyI observed that the key is generating correct whereas the key (as outputs) provided in doctests are different.doctest:
generated output:-
The generated key is : 10110001
The generated key is : 0111110111010010
failed doctest:-
Expected:
'1101101100010000'
Got:
'0111110111010010'
Expected:
'01011011'
Got:
'10110001'
cclauss commentedon Jun 25, 2023
These tests used to pass as they are. I assume that changes made in our dependencies changed the generated key values. Please submit a pull request if you see how to fix the tests.
tianyizheng02 commentedon Jun 25, 2023
@rohan472000 How did you confirm that the keys generated in
mainare correct? The algorithm relies heavily on random numbers, so I'm not sure how we'd confirm that the algorithm is implemented correctly without an external source.tianyizheng02 commentedon Jun 25, 2023
@cclauss The problem is that I believe the contributor originally based the implementation on this Qiskit learning article, but that link is now broken. There's this newer link, but the implementation in this article is significantly different from the contributor's implementation in a few ways. I tried to check whether the current implementation at least matches
but the current implementation outright segfaults. I don't know if there's any way for us to confirm whether the original implementation was ever correct (unless one of us happens to be very familiar with Qiskit and quantum key distribution).
Edit: I found the original Qiskit article on the Wayback Machine (snapshot is from October 2022 and the implementation is from November 2022, so this is the closest version of the article). However, the implementation in this older article appears to be the same as the one in the current article, so I have no idea how the contributor originally came up with their implementation.
rohan472000 commentedon Jun 25, 2023
I'm not confirming it, I was running it locally so I observed that, not sure how it was passing the doctest before.
1 remaining item
rohan472000 commentedon Jun 25, 2023
With this doctest's output that u have provided in PR it will pass definitely as I had tried it also in local, but my question is how the previous outputs were passing correctly and why they r failing now??
rohan472000 commentedon Jun 25, 2023
Ohh..got it now.
abhishekchak52 commentedon Jun 26, 2023
@tianyizheng02 The implementation here is based on a summer research I did before Qiskit textbook had their example up. It is completely equivalent in functionality, just organized differently. Does the segfault problem still exist? Nothing in the example itself allocated memory, so it would be something that changed in the dependencies.
@cclauss Sorry for the late response. I'm spread a little thin at the moment. I gather that the updated doctests fixed the problem?
tianyizheng02 commentedon Jun 26, 2023
The segfault problem still exists. My guess is that it could be due to the large circuit size causing memory issues (Qiskit avoids this in their example by using a list of single-qubit circuits rather than one n-qubit circuit), but I'm not familiar enough with Qiskit to know if this is plausible.
rohan472000 commentedon Jun 26, 2023
@cclauss , in
quantum/q_fourier_transform.pyalso the libqiskitis used, there also doctest are failing in same way asbb84.py.should I raise a PR by changing its output???
cclauss commentedon Jun 26, 2023
What hardware are you running this on? Please document the steps to reproduce. For extra credit, a GitHub Action that demonstrates the segfault. ;-)
I am no FFT guru but my hunch is that the 2500 * 4 dict is the correct answer.
It would be great to get more feedback before we change the expectations to fit the actual.
rohan472000 commentedon Jun 26, 2023
QFT is a probabilistic algorithm, the results will have some variability.
I can see that after running each time I'm getting new outputs. Yeah..Let's wait for more feedback.
[-]Fix failing: `pytest quantum/bb84.py quantum/q_fourier_transform.py`[/-][+]Fix failing: `pytest quantum/q_fourier_transform.py`[/+]tianyizheng02 commentedon Jun 26, 2023
@cclauss My hardware is a MacBook Pro with an Intel i5 chip. You can reproduce the segfault simply by running the file with an input size of 100:
I was testing it on such a large value because n = 100 is the input size used in the Qiskit article's example.
tianyizheng02 commentedon Jun 26, 2023
@cclauss See the failing build for my demo PR #8841 :^)
GitHub Actions build: Add more tests (TheAlgorithms#8837)
quant12345 commentedon Aug 20, 2024
I confirm, each time new values. And there you need to make a correction in the code to run the tests. For example,
executeis removed in new versionsqiskit.Here is the result of two test calls (q_fourier_transform.py):
quantum: modernize QFT to Qiskit 2.x and re-enable its test (#15120)
cclauss commentedon Sep 10, 2026
Python/pyproject.toml
Lines 55 to 63 in bf57384
%
uv venv --python 3.14t && uv pip install qiskit# Fails.