Unexpected (incorrect) measurement #32
Comments
|
A `git bisect' reveals: Given the visualization, 9a0db42 is the most likely first bad commit.
The skipped commits are because they won't compile due to syntax errors. |
|
@quantumkoen Here there is two issues:
I was talking with @kel85uk , and I think it will be good if I have access to this 'random test generation' tool to understand from where the circuit come, and be able to locate the issues whether it is in QX or elsewhere. |
|
@Nader-Khammassi i'm not sure how I reported two issues, I think i had just one: i expected (given the displayed quantum state) to get a measurement of all ones with a very high probability, but what I got was a measurement of 0.....010101 all the time (older versions of qx did give me the all ones, with the exact same code). Anyway, i'll try the fixes. As for the generator, as I just mentioned to @kel85uk this was generated in qiskit with the quantum inspire backend, and that is currently very very experimental, in that it only runs on @peendebak 's machine. I tried to get it working on mine, but ran into issues. Hopefully we can resolve those tomorrow, and we can give you a very early pre-alpha version of that qiskit notebook so you can play with it yourself. |
|
@quantumkoen No problem, I was just mentioning a side 'issue' (not in the Github sens :) ) with the qasm file that can give a false impressions, but for sure, there was one bug and therefore a github issue ! :) I just fixed it in commit ed9e307 . Can you test it, if it fixes the problem, you can close the issue. |
|
@nader i just checked, and this fixes the issue with the unexpected measurement, cool! looks like we're in good shape to merge the whole-shebang into master and call it a 0.2beta release :) As for the float precision issue, indeed something to perhaps pay attention to on 'the other side', the SDK should write out higher precision floats.. of course, given that it's PI, you will never get it right with floats but that's something we can't fix ever.. |
|
@Nader-Khammassi on testing and robustness, I think we should add the example from this issue to the test-suite, it's good practice to always add things that expose a bug, to avoid regressions. As for the short description of what it should do, that's a bit harder. If i'm not mistaken this code is generated to evaluate simulator performance, and was mentioned in this paper: https://arxiv.org/abs/1807.02500 Whether it is supposed to calculate something meaningful, i'm not sure, perhaps @peendebak has some more insight (he actually read the paper, i didn't :). |
|
@quantumkoen Agree, I added it to the test set and just named 'test_i32.qc' to refer to the issue. |
Consider the below (auto-generated) code. The tail end of the output for the dev branch is:
Despite the state
(-0.000002,-0.999997) |1111111111111111> +being the most likely, the measurement shows| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |. An older version of qx-simulator (commit cd9d120) did give a more correct and expected result:The text was updated successfully, but these errors were encountered: