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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GH-6581 introduced a behavior of setting the basis_fidelity used
by decomposer2q from the reported device gate_error of the
corresponding 2q gate. GH-7341 reported a case where this
approximation removed small but significant interactions
resulting in an non-equivalent output circuit. As a workaround,
revert to the prior behavior of using decomposer2q's default
basis_fidelity (1, no approximation).
QiskitGH-6581 introduced a behavior of setting the basis_fidelity used
by decomposer2q from the reported device gate_error of the
corresponding 2q gate. QiskitGH-7341 reported a case where this
approximation removed small but significant interactions
resulting in an non-equivalent output circuit. As a workaround,
revert to the prior behavior of using decomposer2q's default
basis_fidelity (1, no approximation).
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with doing this did you want to have a release note about the change? That being said I don't think we documented it as part of #6581 though so I'm fine with skipping a note on it
Is this going to make it in time for 0.19? There is a set of workshops coming up that relies on having 0.19 and it would be nice to be able to make a statement as to what is expected from the transpiler in terms of its output with respect to input.
Is this going to make it in time for 0.19? There is a set of workshops coming up that relies on having 0.19 and it would be nice to be able to make a statement as to what is expected from the transpiler in terms of its output with respect to input.
It won't be included in 0.19.0, the release is already late and we don't have consensus on the direction for this. Also it is pre-existing behavior from 0.18.0 when the device approximate synthesis default was introduced so trying to rush in something that changes that at this point isn't really viable. I also don't like the current default and would like to fix this, but given we're preparing to release as soon as #7329 merges there isn't time to have the discussion and include this for the release. However, that doesn't rule it out as something we backport to the inevitable 0.19.1 release
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GH-6581 introduced a behavior of setting the basis_fidelity used
by decomposer2q from the reported device gate_error of the
corresponding 2q gate. GH-7341 reported a case where this
approximation removed small but significant interactions
resulting in an non-equivalent output circuit. As a workaround,
revert to the prior behavior of using decomposer2q's default
basis_fidelity (1, no approximation).
Temporarily mitigates #7341.
Summary
Details and comments