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
Refactoring of NoisyOperation, NoisyBasis, OperationRepresentation #1712
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1712 +/- ##
=======================================
Coverage 98.49% 98.49%
=======================================
Files 68 68
Lines 3186 3187 +1
=======================================
+ Hits 3138 3139 +1
Misses 48 48
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
d858f43
to
bed7b3d
Compare
@Misty-W and/or @natestemen , I am fighting with some silly style issues but all other tests are passing. So feel free to review this PR when you have some time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me, but I don't think I fully understand why switching from { op: coeff }
to [ ops ]
and [ coeffs ]
is better. I know in the ticket you mentioned having an ordering is nice, but seeing as there is a tight connection between the operations and coefficients, it does seem natural to me to have them stored in a dictionary. Can you just provide a little more detail on what this achieves?
In terms of future plans, we maybe remove NoisyBasis
altogether in the release after the current one?
ideal, _ = convert_to_mitiq(ideal_operation) | ||
ideal, native_type = convert_to_mitiq(ideal_operation) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this function could take any QPROGRAM
, but previously always returned cirq.Circuit
s. Is my understanding right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what type it was previously returning (since NoisyOperation.circuit
was different) but, yes, it should return a QPROGRAM with the same input type.
Note also that an important update introduced here is that the qubits of the NoisyOperations are replaced by the qubits of the ideal operation that we aim to represent (the input argument of the function). This mapping is superfluous if NoisyOperation._is_qubit_dependent
is True
, but it is necessary when it is False
.
I just added an inline suggestion to avoid useless conversions when NoisyOperation._is_qubit_dependent == True
.
from mitiq.pec.types.types import ( | ||
NoisyBasis, | ||
NoisyOperation, | ||
OperationRepresentation, | ||
NoisyBasis, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does changing the order of imports affect anything, or just reordering to show level of importance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because I first removed NoisyBasis
from Mitiq and then re-added a deprecated version of the NoisyBasis
later. Reordering was not intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To confirm, is the idea of re-adding just to warn the user that NoisyBasis
is deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We can completely remove it in 1 or 2 milestones.
Technically, this is not a deprecation intended in the standard way, which would imply warning but still supporting NoisyBasis
. In our case we just drop it and we give some info to the user with an error message.
Co-authored-by: nate stemen <nate@unitary.fund>
Some motivations:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes: #1659
License