[RFC] Aqua 0.7 Operator Refactor Design Doc

[dongreenberg]

The Operator Redesign doc, copied over from qiskit-community/qiskit-aqua#742. I still need to tweak the doc to reflect the changes below, so please hold off on merging just yet.

Design Review Notes (Action Items marked by AI):

• Initial Impressions
  • Julien (@Cryoris )
    • Good - Operators are designed to be more flexible, and easier to manipulate knowing the math
    • Likes using the same syntax as in Terra, and easy access to the matrix
    • Likes simplified call to expectation and evolution
    • Questions:
      • What happens if you combine combinations?
      • Might prefer a flat hierarchy because of parallels to Composite gate in Terra
  • Panos (@pbark )
    • Good - Overall happy with doc, In favor of positioning closer to Terra
    • Questions
      • How to do rotated operator bases (e.g. Pauline's work)?
  • Stefan (@stefan-woerner )
    • Good: Structure is nice
    • Syntactic sugar is too much for his taste, would rather keep everything explicit in the source code
    • Agrees with Julien about combinations being tricky
  • Yael (@yaelbh )
    • Syntactic sugar may be too tricky
    • Thinks primitives should be in Terra
    • Important to find a solution to the AerExpectation magic branching in Aqua today
  • Steve (@woodsp-ibm )
    • Impression: Need to focus on Operator redesign, because the doc will take too long to implement, and we need to focus and be incremental.
    • Still not clear - how do Expectation and Evolution algos play with the operators?
    • Math between operators - unclear how conversion between types will be affected for combinations
  • Bryce - Listener
  • Paul - Listener
  • Chris (@chriseclectic )
    • Generally agree
    • Needs to be a clear separation between primitive operators which are useful elsewhere and should be in Terra, and what’s just for Aqua
    • Syntactic sugar should be optional, he doesn’t like it but some people do
    • Separating between a data structure, what’s a numeric algorithm on the data structure, and what’s a synthesis algorithm on a composite structure
    • Similarly for conversion between operators, some can’t and can’t be done, and some are exponential or expensive
    • Agrees something needs to be done for Expectation or Evolution between algos and backends
  • Kevin (@kdk )
    • Agrees with Chris about delineation between primitives in Terra and high level in Aqua
    • Joint ownership is the right model
  • Ivano - Listener
• Donny: Themes and questions to answer
  • Themes
    • Much more about building blocks - Reducing the types of objects users need to understand - Make most things in Aqua Operators and Algos
      • E.g. no QuantumInstance, algorithms for different types of Z-sampling
      • Making building blocks lazy means algorithmic subroutines can be returned or passed around more easily
    • Really want to make many recent classes of algorithms of interest possible and natural in Aqua - e.g. Linear combinations of circuits, measuring by linear combinations of stabilizers, evolution by linear combinations of operators
    • Distinction between primitives, which are unique data structures for performance reasons, and composites, which are combinations of primitives to be evaluated lazily later
      • A Clifford class is a tableau, not a circuit with S, CX, and H
    • AI: Label what’s for march and what’s further out and needs further discussion
  • Questions
    • Location of Aqua operator logic?
      • Note: Contrary to what’s in the doc, after discussing with Chris, we’d like to keep primitives in Terra and all other algorithmic operator logic in Aqua, as it doesn’t quite fit with the design of the quantum_info library, and is very Aqua-specific.
      • All in agreement with this split, primitives in Terra, all else in Aqua (for now)? Yes
        • AI Reflect in doc (DONE)
      • Chris: Useful to add a WeightedPauli primitive to Terra that’s a sparse matrix?
        • Panos: Yes
      • Chris: We’d like to add Clifford to Terra and refactor Pauli, but that’s independent work, not tied to the March release deadline.
    • Location of AerExpectation?
      • Chris: This was a hack introduced for immediate performance gains, but hasn't been built out for the many execution modes in Aer or properly formalized, e.g. maybe instruction shouldn’t be expectation, should be “measure in this list of bases.”
      • Leave in Aqua, and build out for Aer migration later
        • Opposition? No
        • AI Reflect in doc (DONE)
      • Maybe we need to have a factory to take an operator and backend and pick an expectation
      • Expectation and Evolution bases can be factories to automatically select an algo based on operator and backend
      • AI Yael - Please write down all the details about the expectation and evolution algos, including factories, both short and long term (DONE)
    • Match Terra’s math overloads?
      • Any opposition to using Terra’s math overloads? No
      • Further discussion about sugar:
        • Matmul is a tricky one because circuit and math conventions are reversed. Let's mimic Terra solution:
          • dot for math direction matmul
          • Compose for circuit direction matmul
          • No @ overload to start (or maybe just dot to match python, but definitely nowhere in source code)
          • AI Reflect in doc (DONE)
        • Avoid sugar in source code as much as possible - All in agreement
        • AI: Think more about kronpower with Chris
          • Stefan - riskiest math overload is kron because no one recognizes ^ from programming
    • Run interface?
      • Steve: This is outside the scope, leave as is - .run()
      • For immediate need - make Expectation and Evolution resemble the existing algo notation.
      • Opposition? No
      • AI Reflect in doc (DONE)
    • Circuit Execution algorithm name?
      • Steve: Also out of scope
      • AI: break out algo scope stuff for multiple docs
        • CircuitExecution
        • Parameterized Algos/Ops
    • Clarification, items for March release:
      • MatrixOperator relying on Terra
      • Introduction of OpSum and OpVec
      • WeightedPauli relying on OpSum
      • Expectation and Evolution algorithms
      • Changing the Aqua algos to rely on Expectation and Evolution
      • AI: Break up work into bugs granularly
    • Chris: Can add more Operator helper methods in Terra to reduce burden of wrapping, e.g. evolution or kronpower
      • AI: Make a list of things we like to add to Terra
• Final reviews (Approve, Conditional Approve, Revisit, Rescope)
  • Approve
    • Julien, Panos, Stefan, Yael, Steve (with code review of object structure in weekly before getting into nitty gritty), Chris, Kevin
  • Cond Approve
  • Revisit
  • Rescope

Final Review: Approved

[dongreenberg]

@mtreinish ping for approval please, as the associated code is already in an PR. Thanks!!