Feature request: state preparation gate

[dabacon]

Is your feature request related to a use case or problem? Please describe.

State preparation is a physical process. In some architectures it is even possible to prepare entangled states. In many cases you want to call this during intermediate steps in the circuit. It would be useful to have a state preparation gate.

Describe the solution you'd like

A gate that allows you to pass in a state:

state = 1/math.sqrt(2) * numpy.array([1, 0, 0, 1])
prep_gate = cirq.PrepareState(state)
circuit.append(prep_gate(q0))

One question is whether this is a channel and if it is a channel is it from dimension 1 to the dimension of the qubits being prepared?

[optional] Describe alternatives/workarounds you've considered

You can combine a cirq.ResetGate with a cirq.MatrixGate

[optional] Additional context (e.g. screenshots)

Arose during discussion of #4048 which asks for the state preparation algorithm, for which there are a ton of different choices.

What is the urgency from your perspective for this issue? Is it blocking important work?

P2 to P3 - we should do it in the next couple of quarters

[stubbi]

@dabacon could you assign me to this one? I am considering taking this one up for some time now and want to give it a try. I might need some time before I will be able to open a PR.

Also, do you see any potential rabbit holes I could tap into? 🐰🕳️

[stubbi]

@balopat thanks! 🙂

[stubbi]

Alright, I had a first look at this and have a few open questions:

1. From @dabacon:

One question is whether this is a channel and if it is a channel is it from dimension 1 to the dimension of the qubits being prepared?

I do not have a good answer to this one. I think it would be simpler for me to implement it as a gate, but I am open to discussion!

2. Do I understand correctly that I can combine the _kraus_ of ResetChannel and _unitary_ of MatrixGate to create the unitary I will need? Or how could I access them if these are supposed to be private functions?

3. Taking the MatrixGate as a blueprint (assuming this can/should be implemented as a gate, cf. question 1), a PrepareState would not need to implement the __pow__ and _phase_by_ functions, correct?

[stubbi]

Looking through #4120 and the cirq-custom-channel RFC I get the feeling that this one should be implemented as a channel as well after #4120 is done. That way, it would be more consistent. But it's just a feeling without being deep into the discussion or the code base

[viathor]

From cirq meeting: cirq's general philosophy is to maintain close correspondence with what is happening on the hardware. From this perspective, the preparation that takes an arbitrary state, as proposed above, is too general. That said, as @dabacon pointed out, some platforms do offer preparations other than |0⟩, some of which are quite powerful (e.g. entangled photon pair preparation using BBO crystals). Therefore, this needs more discussion. Hopefully, we can arrive at a more general preparation than we have at the moment while adhering to the above hardware proximity principle.

[fmozafari]

@dabacon , @viathor
Hi, I thought about adding algorithms for quantum state preparation. Seems you don't require general algorithms for preparing arbitrary quantum states. On the other hand, most of them require an exponential number of elementary quantum gates after decomposition. So, what is your opinion about adding efficient algorithms for preparing specific and important quantum states? such as GHZ state, W state, Dicke state, uniform quantum state, ...
For example, I already implemented the GHZ state preparation as follows:

def ghz_prep(qubit_count: int) -> Circuit:
  """
  Create a quantum circuit that loads a GHZ state.

  Args:
    qubit_count: The number of qubits.

  Returns:
  The corresponding quantum circuit.
  """
  qubits = [cirq.GridQubit(i, 0) for i in range(qubit_count)]
  ghz_circuit = cirq.Circuit()
  ghz_circuit.append(cirq.H(qubits[0]))
  for i in range(qubit_count-1):
    ghz_circuit.append(cirq.CNOT(qubits[i], qubits[i+1]))
  
  return ghz_circuit

[tanujkhattar]

Reviving this old thread based on some newly gained information.

Overview

As per feedback from the physics team (cc @Dripto), it's very common for theorists to follow a pattern where they need to
a) Prepare an arbitrary two qubit state Psi
b) Apply an arbitrary two qubit unitary U on Psi
Given a Psi and U, Cirq is used to construct a circuit in the native gateset which can be run on the hardware.

Prepare an arbitrary two qubit state Psi

This can often be done using specialized implementations which use only a single application of the maximally entangling two qubit gate supported by the hardware. The physics team already has custom utility functions which they use to prepare arbitrary two qubit state using a single application of SQRT_ISWAP or CZ gates.

Note that, Cirq currently does not have any way to doing this efficiently. We could pass the two qubit unitary to analytical decomposition functions convert_to_sqrt_iswaps but it won't be efficient at is it could use upto 3 sqrt iswaps instead of only 1 -- The analytical decomposers are efficient for decomposing unitaries but not preparing arbitrary states.

Apply an arbitrary two qubit unitary U on Psi

The analytical decomposers already present in Cirq are useful here to decompose U into the native target gateset.

Summary / Proposal

We should add a new CircuitOperation/ composite Gate which returns efficient circuits for preparing arbitrary two qubit states for specific native gatesets like sqrt_iswap and czs.

[fmozafari]

@tanujkhattar, Why only 2-qubit states? For example, how do you load the result vector for the HHL algorithm?

[fmozafari]

Reviving this old thread based on some newly gained information.

Overview

As per feedback from the physics team (cc @Dripto), it's very common for theorists to follow a pattern where they need to
a) Prepare an arbitrary two qubit state Psi
b) Apply an arbitrary two qubit unitary U on Psi
Given a Psi and U, Cirq is used to construct a circuit in the native gateset which can be run on the hardware.

Prepare an arbitrary two qubit state Psi

This can often be done using specialized implementations which use only a single application of the maximally entangling two qubit gate supported by the hardware. The physics team already has custom utility functions which they use to prepare arbitrary two qubit state using a single application of SQRT_ISWAP or CZ gates.

Note that, Cirq currently does not have any way to doing this efficiently. We could pass the two qubit unitary to analytical decomposition functions convert_to_sqrt_iswaps but it won't be efficient at is it could use upto 3 sqrt iswaps instead of only 1 -- The analytical decomposers are efficient for decomposing unitaries but not preparing arbitrary states.

Apply an arbitrary two qubit unitary U on Psi

The analytical decomposers already present in Cirq are useful here to decompose U into the native target gateset.

Summary / Proposal

We should add a new CircuitOperation/ composite Gate which returns efficient circuits for preparing arbitrary two qubit states for specific native gatesets like sqrt_iswap and czs.

@tanujkhattar, Why only 2-qubit states? For example, how do you load the result vector for the HHL algorithm?

[Dripto]

Other preparation circuits would also be very useful, and any tool which creates provably efficient circuits in larger scales should certainly also be added if they exist. However in this case I've already written up the two qubit case, since that's what I needed.

[tanujkhattar]

Cirq Sync:

• State preparation is a very useful primitive, but we should have a separate issue / PR for this.
• The original request is to have a generic gate which can be decomposed based on the backend that wants to consume it.