RFCs
RFCs copied to clipboard
Add partial draft of run-time parameters RFC
Apologies, there's quite a lot more I intended to write (and refine the current text) about further parts of the design and my progress, but I now need this to be up and available for others immediately.
I have pushed the branch move-instruction-parameters
to my fork which contains what I have currently done. Roughly, this is:
- added most of the backwards compatibility shim for
Instruction.params
- added a
parameters
field toCircuitInstruction
,DAGOpNode
andDAGDepNode
(the last two might not be complete - I don't think I had fully finished updatingDAGCircuit
andDAGDependency
) - updated the
CircuitInstruction
context class to insert a reference to themselves into containedInstruction
instances - added a first pass at defining a "parameter specification" for
Instruction
instances - added a first (poor) pass at a new
Instruction.decompose
interface to replaceInstruction.definition
. What I've done isn't right at all - my failure here is what caused me to push this from Terra 0.21. The starts of the design in the RFC about defining "input parameters" forQuantumCircuit
are the right way forwards here, and the weird attempts currently in the branch to handleInstruction.decompose
andInstruction.definition
should be completely redone. - made the initialisers of some gates accept zero parameters - in the new preferred form, the rz instruction will be initialised as
RZGate()
, and it's only when we add it to a circuit that we define its operands.
Certainly still to do:
- the "parameter specification" probably needs tweaking (I would keep everything about this private for Terra 0.22, because we'll want to refine the system heavily for typed dynamic parameters)
- all uses of
Instruction.params
(whether through circuits or DAGs) in Terra need updating to the new form. -
QuantumCircuit
needs to learn how to specify input parameters, so we can define the new interface forInstruction.decompose
(orInstruction.definition
). - The new
Instruction.decompose
/Instruction.definition
method needs to be in place so ad-hoc no-subclassInstruction
instances can be created and parameterised correctly (e.g. the return value fromInstruction.inverse
, etc).
Please don't take any of this RFC / any of the code I wrote in my branch on Terra as gospel - a lot of the interfaces doubtless need tweaking or rewriting.