-
Notifications
You must be signed in to change notification settings - Fork 117
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
Mismatch issues of the rz #117
Comments
(2) They are defined in the same way, but the difference is in the matrix we use for the https://github.com/softwareQinc/qpp/blob/main/include/qasm/qasm.hpp#L563 This is the main source of all existing discrepancies. (3) In both However, in the "usual" gate definitions, (1) Using OpenQASM 2's This is also related to #70 |
Thanks for the clarifications for the (2) and (3). I am still referring to the mode I did four tests to show the final states out of In
In
So, the |
Maybe it is more clear if we look at the OpenQASM 3.0 standard library (from https://arxiv.org/pdf/2104.14722.pdf):
This matches the Qiskit specification. However, there is no equivalent to |
I am ignorant of the "inlined" use cases, so I cannot comment on that. Can I read about it somewhere? Any workaround possible to deal with the situation? I don't have any useful suggestions. The identicality of |
One example of a use case is if there are hardware constraints. The staq mapper fully inlines all gates to the builtin U, CX gate set. To resolve the issue, we can define
The extra |
@DevelopDaily can you check this now please? |
Passed the simple test cases. Will test more complex cases... |
The
Executing the example program From the input.qasm:
From the output.qasm:
|
Adding @meamy In staq, those changes are still on the dev branch (not yet merged to main). Can you @DevelopDaily |
From the output.qasm, based on the dev branch:
It still does not match that from the Is it technically possible to preserve the final state of a circuit after it is optimized? The current implementation seems to have been improved significantly. By the way, the |
@meamy any idea? Looks like the final state in output.qasm is (at least at a quick glance) the same up to a phase (the coefficients seem to have same magnitudes as the ones in input.qasm) |
I did another test.
The final state of the I don't know enough about the optimization theory. I did a superficial analysis of the output files from |
@vsoftco There's an issue with the rotation folding optimization with the changes to For the time being, we can merge in the changes and turn off global phase corrections, since they'll be incorrect anyway. This kind of semantics-breaking behaviour is something common in optimizing compilers anyway, but we should note it and plan to fix it eventually. Thanks for the help @DevelopDaily! |
@meamy Thanks, merging into main, but will keep the issue open |
closing here, and leaving it open on staq softwareQinc/staq#45 |
I have noticed three issues related to the
rz
gate.qpp
. The final states are different. The IBM produces the state[ 0.866-0.5j, 0+0j ]
(see the attached screenshot), butqpp [1, 0]
. The optionUSE_OPENQASM2_SPECS=false
is used, so theqpp
result should match that on IBM, shouldn't it?Qiskit result:
In the
preprocessor.hpp
,rz
is defined identically:https://github.com/softwareQinc/qpp/blob/main/qasmtools/include/qasmtools/parser/preprocessor.hpp#L66
https://github.com/softwareQinc/qpp/blob/main/qasmtools/include/qasmtools/parser/preprocessor.hpp#L103
But, their gate implementations are different depending on the
USE_OPENQASM2_SPECS
.https://github.com/softwareQinc/qpp/blob/main/include/qasm/qasm.hpp#L116
Is that a problem?
There seems to be a documentation problem here (https://github.com/softwareQinc/qpp/blob/main/DISCREPANCIES.md) The
rz
difference is not described but it is implemented differently.The text was updated successfully, but these errors were encountered: