Is MatrixGate supported with sympy? If not, can/shall we support it?

[babacry]

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

I wonder if we've already supported / we can support a symbolized MatrixGate like

cirq.MatrixGate(sympy.Symbol('A'))

or

cirq.MatrixGate([[sa,sb],[sc,sd]])

where sa,sb,sc,sd are symbols

Describe the solution you would prefer

I am not an expert of sympy, I understand we need to check dimensions, unitaries for an instantiation of a MatrixGate, wonder what's like and how difficult it is to make MatrixGate compatible with sympy?

How urgent is this for you? Is it blocking important work?

P2/P3. It's good to have, but I have workarouds (see below). I can also workaround in my generic approach in implemeting #6994. Feel free to close this feature request if it's not possible to implement.

Describe alternatives/workarounds you've considered

Convert 2x2 matrix gate to PhXZ gate first then symbolize.

Provide additional information or context (e.g., screenshots)

I need this in supporting #6994, which need some intermediate matrix multiplication numeric sweeps that's better stored in symbolized matrices instead of converting to PhXZ first then symbolize, which requires extra calculation.

[babacry]

cc @eliottrosenberg @NoureldinYosri

[eliottrosenberg]

I suspect this isn't going to be a good way for you to solve your problem. Let's discuss it when you're free. You can put something on my calendar.

[NoureldinYosri]

@babacry why not just get the unitary matrices and multiply them?

[babacry]

I will need to locate where multiply happens and switch back those numerical single qubit gates back to PhXZ with all N set of ResolveParameters.

My initial plan is to use either cirq.merge_operations directly or use merge_operations + transformer_primitives.map_operations_and_unroll, so I can take control of where merging happens, but in this case each merging operations is at 2 operators [op1, op2], merge_func(op1, op2)'s return needs to be sweeps of (MatrixGate('A') with N set of numerics of this matrix would be great). I figure this might be a feature that is already supported / good to have, so I post it here.

Another option for me is to multiply numerics of 2x2 matrices then locate all the merging locations by tagging them in the rewriter of merge_k_qubit_unitaries or tagging in merge_func of merge operations.

Any other suggestions on locating the merges?

[NoureldinYosri]

@babacry simple does the trick

def merge_single_qubit_ops(op1, op2):
      # merge using unitaries and return PhasedXZGate

def transform_circuit(circuit, sweep):
  prv_op = {}
  new_ops = []
  for op in circuit.all_operations():
     if cirq.num_qubits(op) == 1:
         q, = op.qubits
         prv_op[q] = merge_single_qubit_op(prv_op.get(q, None), op)
         continue

      for q in op.qubits:
          if q in prv_op:
               new_ops.append(prv_op[q])
               del prv_op[q]
      new_ops.append(op)
  new_ops.extend(prv_op.values())
  return cirq.Circuit(new_ops)

later we can add a sweep parameter to the functions

[daxfohl]

There's also a cirq.mul protocol that could be useful here, since unitaries are usually not available for parameterized gates, as the return type is a numpy array. Implementing PhasedXZGate.__mul__ and __rmul__ explicitly would let you handle cases where the unitary is not available, as well as improve perf for cases where calculating the unitary is expensive and can be avoided.

[babacry]

Thanks for the suggestions. I will probably close this feature request as I was just thinking if such thing exists or is a low hanging fruits that can be easily implemented.

Eliott, I have different implementation approaches in my mind, the first approach apparently failed as I though I can store things via "MatrixGate('A')". I've tried other approaches under the util functions in transformer_primitives, which I think is the best way to handle all the corner cases we will possibly meet in implementations, #7149 worked IMO, though I still need to fix it, but it would be great if you can do some local test.

Nour, thanks for the idea, I was thinking about looping the ops myself, but that requires extra care in handling all the corner cases including recursive transformation and I need to keep track of a lot of variables, which are already handled in the existing modules of transformer_primitives, e.g., merge_operations, merge_k_qubit_gates etc. So I would prefer using the existing function. It generally worked in #7149, but I still need to fix the draft pr.

Dax, good to know cirq.mul and we can implement PhasedXZGate.__mult___ and PhasedXZGate__rmult__, I will probably explore deeper and play around with cirq.mul and submit code to support this once I got time.