Improve braket support

[rmlarose]

Initial braket support was added in #590, but there are a few remaining tasks to complete - see the TODO's in mitiq_braket.conversions. This issue is to complete those TODO's.

[maxtremblay]

Hello, I made some progress on this issue. However, I don't find a translation in term of basic gates for some braket operations like CPhaseShift00. So for now, I plan to use

return [cirq_ops.MatrixGate(gate.to_matrix()).on(*qubits)]

I tested it and it works fine. In fact, I think it can be a good fallback for any non-standard two-qubit gate. What do you think about that?

[maxtremblay]

Also, as I side note, in the _translate_cirq_operation_to_braket_instruction and _translate_braket_instruction_to_cirq_operation functions, if the gate is a 3-qubit gates, but not a Toffoli nor a Fredkin, the functions don't return (or return None if you prefer), but raise an error for all other failures.

If this is not desired, I could fix that in the same PR if you want?

[nathanshammah]

Hi @maxtremblay, thanks for the comments and questions. The option above for MatrixGate looks reasonable to me. Maybe for the 3-qubit gate question, @rmlarose or @andreamari have some advice?

[andreamari]

Hello, I made some progress on this issue. However, I don't find a translation in term of basic gates for some braket operations like CPhaseShift00. So for now, I plan to use

return [cirq_ops.MatrixGate(gate.to_matrix()).on(*qubits)]

I tested it and it works fine. In fact, I think it can be a good fallback for any non-standard two-qubit gate. What do you think about that?

MatrixGate could be a fallback option but, if I am not wrong, I think it makes it hard to translate back to Braket. Instead I found this decomposition which could be useful: https://github.com/aws/amazon-braket-pennylane-plugin-python/blob/f52d02f8e6fab66e8ee764df2ad723327ba68307/src/braket/pennylane_plugin/ops.py#L116

[andreamari]

About the second question on the 3 qubit gates, I think you are right. I didn't check but the solution is probably to remove the final else before the error: https://github.com/unitaryfund/mitiq/blob/2309b08acbacf2c056f76293a9c28421ddd55d11/mitiq/mitiq_braket/conversions.py#L93

[maxtremblay]

I can do some decompositions into a sequence of gates, however, this would involve updating the test function since right now, it assumes that to each braket gate corresponds a single cirq gate.

https://github.com/unitaryfund/mitiq/blob/2309b08acbacf2c056f76293a9c28421ddd55d11/mitiq/mitiq_braket/tests/test_conversions_braket.py#L142-L163

Also, I think a simpler decomposition is to apply a XX, XI, IX after a CZ^(angle / 2) to map CPhaseShift to CPhaseShift00, CPhaseShift01 and CPhaseShift10 respectively.

[andreamari]

Thanks @maxtremblay! If you found a simpler decomposition, you can use it. Don't worry for the existing test. We can add a new test function dedicated only to the particular case of CPhaseShift00.

Just to clarify my view: I am fine also with the MatrixGate if it works. However, I think it makes sense only if the following pipeline works:

• Braket to Cirq conversion: CPhaseShift00(theta) ----> MatrixGate(...)
• Cirq processing by Mitiq, for example: MatrixGate(...) ----> [MatrixGate(...), inverse of MatrixGate(...), MatrixGate(...)]
• Cirq to Braket conversion: [MatrixGate(...), inverse of MatrixGate(...), MatrixGate(...)] ---> [CPhaseShift00(theta), CPhaseShift00(-theta), CPhaseShift00(theta)]

With the current code, the brute force kak_decomposition (12 gates) would be produced for each phase shift. I think this is worst than directly starting from a known decomposition in the first place. Unless we apply more advanced tricks to manually recognize if a MatrixGate corresponds to a 00 phase shift.

[rmlarose]

MatrixGate could be a fallback option but, if I am not wrong, I think it makes it hard to translate back to Braket.

+1. MatrixGate should only be used as a last resort. It is better to have a decomposition.

[rmlarose]

This was closed by #688.