forked from Qiskit/qiskit
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Change data type of
QuantumCircuit.data
elements (Qiskit#8093)
* Convert QuantumCircuit.data items to CircuitInstruction This introduces a new, lightweight class `CircuitInstruction` the encapsulates the previous 3-tuple that made up the items of `QuantumCircuit.data`. It includes a legacy API that makes the object appear to be the old 3-tuple when used as if it were that tuple, and the relatively small changeset for this commit is an approximate indication that these should mostly be suitable. There will be significant performance penalties for accessing the legacy interface, however, due to some internal type conversions, so it is a matter of priority to convert internal usage to the new dotted-attribute access form. The only places necessary to change across Terra were those where the data elements were compared by referential equality to expected values (such as in the control-flow builders), and places that were invalidly accessing the private attribute `QuantumCircuit._data`. All these are updated. `ParameterTable` should in the future be changed to operate over this entire context, but that was beyond the scope of the initial commit. * Convert all usage of data tuple to CircuitInstruction This previous commit is the minimal set of changes needed for the entire test suite to pass, but large parts of Terra and the test suite were still using the backwards-compatibility shims when dealing with `QuantumCircuit.data`. This changes over every single usage within Terra to use the new dotted-access form, rather than the tuple indexing or iteration that previously existed. The internal types of the `qargs` and `cargs` in `DAGDepNode` and `DAGOpNode` are also changed to be `tuple` now; previously they were semi-undefined, and in some cases were not consistent, but not caught in the test suite. Since changing the type of the `qubits` parameter in `CircuitInstruction` to be tuple (unless using the backwards-compatibility shims), this caused a lot of failures where the value was being assigned directly. Normalising to `tuple` has the same benefit as it does in the circuit instruction - less copying overhead, and no worrying about multiple writable references to the same object. By far the largest set of changes are in the test suite; we do a lot of comparing things for exact equality, and since the type is now changed from `list` to `tuple`, all the tests had to be updated. This isn't expected to have much impact on user code, but changing the type to an immutable one has large benefits for us when copying these data structures. * Correct bad version in comment * Simplify unnecessary if/else * Update remnant legacy interface uses Some uses of the legacy interface related to directly setting `QuantumCircuit.data` had slipped through the cracks. A bug in `astroid` caused its inference to fail, and think that these settings made the scalar type of `QuantumCircuit.data` the old 3-tuple after it saw these settings. Since there's a property setter for `data`, that's a bug in `astroid`, but it still turned up some useful additional cases that were useful to correct. * Remove accidental blank line * Use QuantumCircuit.copy_empty_like in Instruction constructors * Correct global phase in Instruction.inverse * Shut pylint up about consider-using-generator pylint isn't actually correct in this case. `tuple(<list comp>)` is more efficient than `tuple(<generator>)` (certainly as of Python 3.10), because Python still needs to use a temporary vector-like expanding collection while consuming the iterable so despite appearances there's no memory benefit to the generator, and list comprehensions are translated into faster bytecode than general generators. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
- Loading branch information
1 parent
42c72be
commit ea02667
Showing
106 changed files
with
2,151 additions
and
1,961 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
Oops, something went wrong.