Skip to content
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

Make heuristic score sorting robust in 1q optimization pass #9239

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -112,13 +112,18 @@ def _substitution_checks(self, dag, old_run, new_circ, basis, qubit):
# if we're outside of the basis set, we're obligated to logically decompose.
# if we're outside of the set of gates for which we have physical definitions,
# then we _try_ to decompose, using the results if we see improvement.
new_error = _error(new_circ, self._target, qubit)
Copy link
Contributor

@kevinhartman kevinhartman Dec 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's overkill, but I think it might be cleaner and less error-prone to add a local class to encapsulate the error tuple, and then generate a total ordering for it with @functools.total_ordering.

It looks like _error is used by _resynthesize_run as a key to min soI'd worry there might be times where code accidentally compares tuples to numbers.

EDIT: crossed-out isn't relevant (didn't notice at first glance that the target is bound as the same for all).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tuple[T, ...] has an automatic total ordering in Python if type T has a total ordering itself, regardless of whether the lengths match - using tuples in comparisons is fairly idiomatic (e.g. if sys.version_info < (3, 10) etc). Maybe I'm misunderstanding what you meant, though.

if isinstance(new_error, tuple):
error_rate = new_error[0]
else:
error_rate = new_error
Comment on lines +115 to +119
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If target is None, the output of _error is the length of the circuit, which isn't really an error rate. Is that what you meant to happen? If so, we could change the function to just return (len(circuit),) instead to simplify some checking.

return (
uncalibrated_and_not_basis_p
or (
uncalibrated_p
and _error(new_circ, self._target, qubit) < _error(old_run, self._target, qubit)
and new_error < _error(old_run, self._target, qubit)
)
or np.isclose(_error(new_circ, self._target, qubit), 0)
or np.isclose(error_rate, 0)
Comment on lines -121 to +126
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check feels weird, because before this PR the last line could only have triggered if the error rate was "close to" 0, but not actually 0 - in that case, it would have been replaced by -100 + len(circuit), so not be close any more. I'm not sure if that was intended - the behaviour it'll have after this PR (anything "close to" zero triggers the replacement) feels more natural to me.

)

@control_flow.trivial_recurse
Expand Down Expand Up @@ -189,7 +194,4 @@ def _error(circuit, target, qubit):
for inst in circuit
]
gate_error = 1 - np.product(gate_fidelities)
if gate_error == 0.0:
return -100 + len(circuit) # prefer shorter circuits among those with zero error
else:
return gate_error
return (gate_error, len(circuit))