[RFC] Ansatz Design Doc

[Cryoris]

Migrating from qiskit-community/qiskit-aqua#747.

This design doc/rfc is in jupyter notebook format and schematically follows the md template. As you pointed out in #1, we'd need a ipynb template as well (maybe it's sufficient to just 'translate' the md one?).

What should we do with images contained in the RFC? For now I created a folder according to the RFC naming scheme containing the notebook along with the images.

[claassistantio]

All committers have signed the CLA.

[dongreenberg]

Hey Julien, two things:

1. Newcomers may not know what part of qiskit "Ansatz Design Doc" refers to. Maybe we can change it to "Aqua 0.7 Ansatz Design Doc"?
2. Could you please copy the following into the top of the doc, under the title, as in the rfc template (and fill it out)? For submitted, you can use the day when you sent it for design review. For deprecated, you can just put "N/A". For status, please put "Accepted."

Status	Proposed/Accepted/Deprecated
RFC #	####
Authors	First Author ([email protected]), ...
Deprecates	RFC that this RFC deprecates
Submitted	YYYY-MM-DD
Updated	YYYY-MM-DD

[dongreenberg]

Notes from design review:

Notetaker/Steering: Donny

• High-level Impressions
  • Kevin (@kdk )
    • Terra can help in some areas, e.g. Barriers for print but not transpilation
    • Should clarify what the Terra objects under the hood will be, or hide them, so as not to confuse users
    • Should think harder about eager transpilation timing, so transpile only happens when we know about the backend
  • Stefan (@stefan-woerner )
    • What is the difference between the three types of terra circuits?
    • Transpilation - there is a difference between optimizing the gate and transpiling for hardware
    • Initialstate, UncertaintyModel - All overlapping, should be made the same
  • Panos (@pbark )
    • Transpilation - Not doable to do pre-transpilation, because it depends on the parameters. Would be hard if doable.
    • Agrees with Stefan that more thought needs to go into organizing Featuremaps, InitialState, etc.
    • Inserting parameters will be difficult and maybe overly complicated
  • Christa (@Zoufalc )
    • We need the gate insertion for gradients
    • Initial state and uncertainty problem isn’t really an ansatz, it’s just a fixed circuit
  • Ali (@ajavadia )
    • Implementation - Should this just be derived from QuantumCircuit, or gate or something else, because it has a lot of overlapping functionality (append, etc.)?
    • Difference between circuit, gate, instr - On our radar. Transpiling only one section of a gate should work by transpiling a circuit, and then calling to_gate(), and using that as is.
  • Steve (@woodsp-ibm )
    • Originally, Aqua came from a place where components were each pieces of circuits. We didn’t care what was under the hood, but want a consistent interface. Whatever we do here should be the same in the all the components.
    • It’s good to have common classes, but not necessary to mush everything, e.g. InitialState, together into one class just to say we did.
    • Parameters, transpile - if it’s not necessary to pass hardware information we shouldn’t. It would be better to just pass the user a circuit and have them transpile.
    • Mutability - If I have an Ansatz and do an append, will the algorithm understand? If you want to build an ansatz, can you just stack some together, instead of building complicated functionality to modify?
  • Donny (@dongreenberg )
    • Like that the purpose of the Anastz as a thing that provides a service of repeating gates, and like Ali’s point that maybe this is just a sparse representation of a circuit.
    • Context on transpile - when we got rid of caching, we started trying to do this eager transpile.
• Julien (@Cryoris )
  • Philosophy
    • Python is a language with lots of syntactic sugar and just works, and wanted to see that in the ansatz.
    • Wanted things to be easy to understand across Aqua, where if you understand the Ansatz you realize that you understand the Featuremap and other too.
    • Backward compatibility
  • Questions
    • Bounds - The Ansatz has bounds, but doesn’t enforce them. Should a gate have bounds?
      • Unresolved, table for later
    • Can we support a “parameterized_circuit” property in the gate?
      • Kevin: yes
    • Inherit or hold Circuit / Gate / Instruction?
      • Table for later
    • Combining things - InitialState, FeatureMap, etc. motivation is just to simplify these to make them familiar.
• Ratings
  • All - Conditionally Approve, pending resolving Circuit inheritance vs. encapsulation discussion.

After follow up discussion, it was decided for the Ansatz to hold a gate or circuit, rather than inherit from Gate or QuantumCircuit, to allow for some flexibility as this design settles (inheritance introduces strong coupling which is hard to extricate later), and to allow for diverse Ansatze, such as linear combinations of circuits, not-gate.

Final rating: Approved

[dongreenberg]

Please just fix changes mentioned in comments above. Also please change the number in the filenames and top section of the doc to 0001.

[Cryoris]

@dongreenberg Updated!