Interface

[diagonal-hamiltonian]

#40 lets spitball

[robertodr]

Copying the message you posted elsewhere:

# ═══════════════ MAJORANA ═══════════════      ║  ═══════════════ PAULI (qubit) ═══════════════
from monoprop import (MajoranaPropagator,        #  from monoprop import (PauliPropagator,
    MajoranaGate, MajoranaCircuit)               #      PauliGate, PauliCircuit)
from monoprop.majorana_data import MajoranaOperator  # from monoprop.pauli_data import PauliOperator

# 1. Observable                                  ║
obs = MajoranaOperator.from_dict(                #  obs = PauliOperator(["ZZ"], [1.0])
    {(0, 1): 1.0j}, num_modes=2)                 #  #  num_qubits inferred from string length

# 2. Gates — pure generators (no angle on them)  ║
g0 = MajoranaGate(                               #  g0 = PauliGate((0,),
    MajoranaOperator.from_dict({(0,): 1.0}))     #      PauliOperator(["X"], [1.0]))
g1 = MajoranaGate(                               #  g1 = PauliGate((0, 1),
    MajoranaOperator.from_dict({(2, 3): 1.0j}))  #      PauliOperator(["ZZ"], [1.0]))

# 3. Circuit — gates + angle values + mapping    ║
circ = MajoranaCircuit(                          #  circ = PauliCircuit(
    (g0, g1), parameters=(0.3, 0.7),             #      (g0, g1), parameters=(0.3, 0.7),
    initial_state=(0, 1))                        #      initial_state=(), num_qubits=2)

# 4. Propagator                                  ║
mp = MajoranaPropagator.from_circuit(            #  pp = PauliPropagator.from_circuit(
    circ, obs, cutoff=4)                         #      circ, obs, cutoff=2)

Ways to propgate:

# A. from_circuit — construct + build the reusable graph in one step (most common)
mp = MajoranaPropagator.from_circuit(circ, obs, cutoff=4)
val = mp.expectation_value(circ)          # replay at the circuit's angles

# B. construct, then build_graph — when you build the graph incrementally / reuse it
mp = MajoranaPropagator(obs, initial_state=[0, 1], cutoff=4)
mp.build_graph(circ)                       # graph now owns the gates + mapping
val = mp.expectation_value([0.3, 0.7])     # re-evaluate at any angles, cheaply

# C. propagate — one-shot, no graph stored (memory-lean, single contraction)
mp = MajoranaPropagator(obs, initial_state=[0, 1], cutoff=4)
mp.propagate(circ)
op = mp.evolved_operator()                 # {majorana-index-tuple: complex}

[diagonal-hamiltonian]

and if MajoranaOperator represents a hermitian object then it makes sense

[diagonal-hamiltonian]

so a gate should be like MajoranaGate(MajoranaOperator() | dict) where there is a consistency check on the dict when input?

[robertodr]

Hermiticiy can be enforced in the init, I don't see a problem with that.

[SimoneGasperini]

Is the idea to support all A. B. and C. modes?

[SimoneGasperini]

I don't understand how you want to pass the numerical parameters. In B. they are passed only at the end to compute the expval: makes sense, but aren't the parameters also contained in the circ you pass at the previous line? (like it happens in C. I guess)

[robertodr]

Tagging people with relevant opinions:
@ludmilaasb @MGDelcey @matteoacrossi @adamglos92 @ozlemsalehi @antonnykanen

[SimoneGasperini]

1. we can re-export MajoranaOperator PauliOperator to the top-level monoprop module, so the user doens't need to remember which submodule they come from.

In my opinion the cleanest and most intuitive way for a user would be:

from monoprop.majorana import ...
from monoprop.pauli import ...

[robertodr]

Either everything is in submodules or everything is top-level. As long as we're consistent

[SimoneGasperini]

Ok yes but I imagine something like:

from monoprop import MonomialPropagator  # base class that we will eventually use in the future to support any basis
from monoprop.majorana import MajoranaPropagator, MajoranaOperator, MajoranaGate, MajoranaCircuit
from monoprop.pauli import PauliPropagator, PauliOperator, PauliGate, PauliCircuit

[robertodr]

Regarding ways to propagate, I think the most important distinction is Heisenberg vs Schrodinger, not Majorana vs Pauli. Do you have examples for the two pictures?

[diagonal-hamiltonian]

its the same old supply a schrodinger cutoff to evolve in schrodinger picture - default is heis

[SimoneGasperini]

Isn't Heisenberg/Schrodinger a setting of the propagator itself? I guess it is, so I would pass it when creating the propagator 🐊

[SimoneGasperini]

I we assume Heisenberg picture to be the default, I would just add a schrodinger boolean flag with default False:

mp = MajoranaPropagator(circ, obs, cutoff=4)  # heis picture
# or
mp = MajoranaPropagator(circ, obs, cutoff=4, schrodinger=True)  # shro picture

I honestly find confusing to have two different parameters cutoff and schrodinger_cutoff...

mp = MajoranaPropagator(circ, obs, cutoff=4, schrodinger_cutoff=6)  💀

[SimoneGasperini]

2. MajoranaOperator is from_dict but PauliOperator has a proper __init__ make the two classes homogeneous in their initialization (either both only use from_dict or only use __init__ or both have both ways).

I would go for __init__ only for both. I don't see any particular meaning in creating a Majorana/Pauli operator from a dictionary (especially if there is only one way to do that).

[SimoneGasperini]

3. I would not allow inferring number of qubits from string length, explicit is better than implicit.

I totally agree. Also, what if I need to create e.g. the $Z_{34} Z_{35}$ operator for a 100 qubits system? In my opinion we should have a "sparse way" to do that without having to pass the full string "...IIIIIIIIIIZZIIIIIIIIII..." maybe.

[diagonal-hamiltonian]

yeah .. I have the option to specify qubits

[diagonal-hamiltonian]

unless i removed it

[SimoneGasperini]

This might help: SparsePauliOp.from_sparse_list

[ludmilaasb]

The qubits the operator is acting on are defined in the PauliEvGate

[ludmilaasb]

But yes, it could even more compact

[SimoneGasperini]

@diagonal-hamiltonian @robertodr Question: do we really need to have a MajoranaGate class and a PauliGate class? We could build the circuit directly passing the list of generators of the gates (as MajoranaOperator or PauliOperator) and the list of their coefficients to represent the unitaries $e^{-i \theta G}$. Maybe gates are a useless abstraction in our case, especially if the only way we support to build a gate is passing its generator operator.

[SimoneGasperini]

This would allow to skip completely step 2. leaving step 3. basically unchanged

[SimoneGasperini]

Note that a unitary gate is a more complex object because its generator may be a linear combination of operators... And in general those might be non-commuting operators as well!

[SimoneGasperini]

Also, the propagation algorithm works playing directly with generators so maybe we don't need the concept of gate at all

[SimoneGasperini]

# A. from_circuit — construct + build the reusable graph in one step (most common)
mp = MajoranaPropagator.from_circuit(circ, obs, cutoff=4)
val = mp.expectation_value(circ)          # replay at the circuit's angles

# B. construct, then build_graph — when you build the graph incrementally / reuse it
mp = MajoranaPropagator(obs, initial_state=[0, 1], cutoff=4)
mp.build_graph(circ)                       # graph now owns the gates + mapping
val = mp.expectation_value([0.3, 0.7])     # re-evaluate at any angles, cheaply

# C. propagate — one-shot, no graph stored (memory-lean, single contraction)
mp = MajoranaPropagator(obs, initial_state=[0, 1], cutoff=4)
mp.propagate(circ)
op = mp.evolved_operator()                 # {majorana-index-tuple: complex}

I don't like A. because we are passing circ twice... 🤔

I like the idea of supporting both B. and C. but initial_state should be removed from the initialization of the propagator because that information is already contained in the circuit, isn't it?

[ludmilaasb]

Also, I think we should treat getting circuits from 3rd libraries as optional, an extra feature for convinience, not the default behavior. Those are pluggings: the pipeline does not and should not depend on it (otherwise our library is plugging for 3rd party!)

The user should be able to define their their initial state and gates to be propagated with the types we provide.

[diagonal-hamiltonian]

I mean its not that difficult really so i dont know

[diagonal-hamiltonian]

theres many ways to skin a cat and there are many ways to design a nice interface

[ludmilaasb]

Many ways indeed, but simpler/well defined is better.

I took a second look, and I think that approach A is indeed the fastest/easiest IF the goal is to the simulator get the data and change it internal state immediately. And since this works a bit different from B, C, why do we need them to share the same types with method A?

I think as a compromise we could have the following:

• A quantum circuit class, as you said
• Another class that contains only a sequence of gates.

In that way, the Quantum Circuit class contains the later one: it holds both QuantunGates and InitialState.

The responsibilities are isolated, and we have proper types which fits different ways to use the simulator.

What do you guys think?

[MGDelcey]

My 2 cents after quickly browsing this long chat.
Why do we want the circuit object? Is it because this is how we would eventually output an actual quantum circuit to be run on HW?
Because it feels a bit like the quantum circuit is not be most natural input parameter. Sometimes we want to use the parameters, sometimes not and the initial state feels intuitively quite separate from the gate sequence.

Would the best be to use each of these things separately, and only provide the Quantum Circuit class as a convenience for the user to then output a qiskit circuit?