-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Add QuantumCircuit.ensure_physical
#14779
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
base: main
Are you sure you want to change the base?
Add QuantumCircuit.ensure_physical
#14779
Conversation
This is similar but stronger to `DAGCircuit::make_physical`. Since `QuantumCircuit` also has layout information available, this method safely handles this, and the case that the circuit has already been made physical. The new documentation in the circuit module and the `QuantumCircuit` class is intended to help, since this is a common point of confusion among both users and developers; the documentation isn't supposed to be a strong personal endorsement of the current situation, just an explicit statement of what the current system _is_. This commit was motivated by ad-hoc attempts to do this, such as in `QuantumCircuit._from_circuit_data(add_regs=True)` (which can be updated to use this in a follow-up).
One or more of the following people are relevant to this code:
|
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.
👍
/// Args: | ||
/// num_qubits: if given, the total number of physical qubits in the output; it must be at | ||
/// least as large as the number of qubits in the circuit. If not given, the number of | ||
/// qubits is unchanged. |
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.
You know qiskit style better than me, but I'll mention in case it is an oversight rather than intentional: do you want a Raises:
section here?
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.
we're pretty lax with "Raises" sections - I don't usually add them when the only exceptions are things like ValueError
for things that are fairly obviously incorrect inputs. If you go down that route, basically everything in Python can raise runtime exceptions (TypeError
/IndexError
/ValueError
and all sorts), so I tend to only put them for non-obvious Qiskit-specific things.
Pull Request Test Coverage Report for Build 16445290736Details
💛 - Coveralls |
This is similar but stronger to
DAGCircuit::make_physical
. SinceQuantumCircuit
also has layout information available, this method safely handles this, and the case that the circuit has already been made physical.The new documentation in the circuit module and the
QuantumCircuit
class is intended to help, since this is a common point of confusion among both users and developers; the documentation isn't supposed to be a strong personal endorsement of the current situation, just an explicit statement of what the current system is.This commit was motivated by ad-hoc attempts to do this, such as in
QuantumCircuit._from_circuit_data(add_regs=True)
(which can be updated to use this in a follow-up).Summary
Details and comments
The reason that the
QuantumCircuit
method is calledensure_physical
and theDAGCircuit
one is calledmake_physical
is because the DAG one doesn't have the same information available to it about what (if anything) the current layout is (in the current Qiskit data flow, the layout, if any, is in thePropertySet
while transpilation is ongoing), so it can't really do a proper verification; it's always an active modification. TheQuantumCircuit
variant can tell if a circuit is already laid out.