Gate decomposition

[speller26]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Right now, the Amazon Braket provider translates gates from Qiskit to Braket with a hardcoded dicts. This limits the Qiskit operations that can be used in Braket. For example, the circuit

circuit = QuantumCircuit(1)
circuit.prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

cannot run because StatePreparation is not explicitly in the dict. Likewise,

operator = (Z ^ Z) - 0.1 * (X ^ I)
evo = PauliEvolutionGate(operator, time=0.2)
circuit = SuzukiTrotter().synthesize(evo)

cannot run because of the absence of exponential operators. These circuits can run on Braket provided they are sufficiently decomposed.

Another example of an unsupported gate is the U gate;

circuit = QuantumCircuit(1)
circuit.u(np.pi/2, np.pi/3, np.pi/4, 0)

cannot run, regardless of how many times decompose() is called, because U is the final step of the decomposition; for gates such as these, the decomposition needs to be handled directly.

What is the expected behavior?

Gats should be automatically decomposed to be compatible with Amazon Braket devices, and gates that cannot be made compatible with (built-in) decomposition should be converted in the provider.

Acceptance criteria

A circuit with any standard gate (aside from global phase) should run successfully, as well as each of the circuits described above; these should all be included as test cases.

[AbdullahKazi500]

can you assign me this issue @speller26

[abrassel]

I am also interested in working on this issue.

[Gmontes01]

Hello, I would also like to be assigned to this project @speller26

[s-aldaihan]

I am also interested in this issue @speller26

[JordanAWS]

Since multiple people (@s-aldaihan , @Gmontes01 , @AbdullahKazi500, @abrassel ) have volunteered for this issue, I will assign it to all of you.

Here are the rules: you can either
A) Work together on this issue and split the bounty (very reasonable idea for a project of this size!)
B) Each work independently and race to the finish line. The first person to submit a working PR (including tests) will win the full bounty.

Please let me know what you each prefer by reacting to to this message with an 🅰️ or 🅱️ :)

If a subset of hackers react A, I will take that to mean they are forming a team to work on this issue, and if anyone else reacts B, I will take that to mean that hacker is working independently.

[Gmontes01]

🅰️ I'm happy to work with y'all.

[abrassel]

I'm happy to collaborate

[s-aldaihan]

🅰️ I am happy to collaborate as well

[AbdullahKazi500]

I am open to collaborate

[DarthRevan07]

@speller26 Hi! Since my fellow Qbrainiacs have already started working on this issue collaboratively, i'd like to work independently on this and race them to the finish line. Can you assign it to me?

[Gmontes01]

@speller26 I ended up working alone to build my code and feel confident in racing towards the end on my own. Can I switch back to working on this on my own?

[abrassel]

I don't really want to participate in a race, so happy to tap out.

[JordanAWS]

@Gmontes01 Hm, this is a tough one. Generally we don't want to encourage switching from a team to solo partway through the hackathon.

@AbdullahKazi500 and @s-aldaihan, can you tell me how far along you are in working on this issue? Were you counting on working with a team, or are you okay with doing a race?

[AbdullahKazi500]

Hi @JordanAWS I am more on a learning path than competing although this is my second Unitary fund hackathon I am open for collaboration before this I have worked with Stanford and MIT Postdoc students having 27 Papers in experimental research but I am new to opensource so I am trying to figure out whatever I can get

[s-aldaihan]

I am familiarizing myself with Braket and exploring ways to map unsupported gates @JordanAWS . Still happy to collaborate if someone is open to working together.

[Gmontes01]

Looks like we got the team finally rolling @JordanAWS. I'm happy to join y'all and split the work. Join my discord @s-aldaihan and @AbdullahKazi500 and we can get started!

Gate Decomp Group
Hopefully this link works!

[Gmontes01]

A couple questions @JordanAWS and @speller26

1. the decompose() method is found in the qiskit terra source code, so I understand that I will not be able to alter its functionality through a pull request in this branch. Should I focus more on implementing and working around the limitations of the given decompose() method as a step in translating from qiskit to braket?
2. My handling of my state_preparation() gate relies on the assumption that a qubit is initially in a zero state and I cannot think of any way to properly preparing a known state without first being in a known state. Is there any braket equivalent to qiskit's .reset() operator and if not can we make adding that functionality a different task given that .reset() is a standard operation and not a standard gate so its outside the scope of this branch?
3. I noticed that global phase is allowed to shift during the handling of other qiskit operations, mainly 'u3' and the new 'u'. Should I be worried about having the proper global phase shift, specifically for my handling of state_preparation() and u()?
4. I currently plan to test the handling of the state_preparation() gate through translating a 1 qubit gate to braket then running the braket gate on a simulator and confirming the final state vector of the braket gate. Should I take a similar approach to testing the u gate or should something else be taken?

[kshitijc]

1. Yes, that is correct.
2. There isn't a reset operator in Braket today, but from what I can see here, it seems like qiskit.extensions.Initialize requires a reset instruction but StatePreparation doesn't. Are there cases where it is still needed?
3. What issues do you run into if you try to handle the global phase?
4. That sounds like a reasonable approach to me.

[Gmontes01]

2. The main concern that I have about not using a reset instruction is the case where someone alters a qubit's state and then applies the .prepare_state(state_vec) and converts that circuit into a braket circuit. The conversion of this circuit would not prepare the desired state_vec because the braket equivalent of the prepare_state() method applies its transformations to a starting state which is not zero. Thus the adapter would be able to successfully adapt the code

circuit = QuantumCircuit(1)
circuit.prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

into a braket circuit which prepares the desired state but would fail to produce the desired state from the code

circuit = QuantumCircuit(1)
circuit..x(0).prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

because the starting position of the qubit 0 would not be in the zero position when the qubit has the transformations associated to prepare_state() applied to it.

3. I actually have no issues when I handle the global phase. I run into issues when I do not handle the global phase and I am unsure if my handling of the global phase might be extraneous or cause errors somewhere else

[mmlouamri]

Hi!

I have given this issue a try #103 and I would appreciate any guidance or feedback from the maintainers on my approach :). Thank you

[kshitijc]

@Gmontes01
2. I think it is reasonable to assume that the prepare_state() method if invoked on a circuit with other operations already applied, doesn't yield a circuit with final state as the one specified in prepare_state.
3. Ok, let's try to implement handling global phase for now then and see how we can handle any issues which might arise.

[Gmontes01]

@kshitijc
2. I read up on the qiskit implementation of the prepare_state() method our handling will be consistent with the way qiskit handles the gate so despite there still being a slight problem with the lack of a reset operation I am content having the translated circuit be consistent with qiskit.
3. I implemented global phase handling. Perhaps the phase handling can be done more elloquently with a build in gate for transforming global phase but the issue shows up infrequently enough that I am content just writing it out the two time a global phase shift is needed.

@JordanAWS @speller26
Please let me know how this recent pull request looks and if there is anything I may be missing to earn the UnitaryFund bounty! I'm still fairly new to contributing to open source so I am happy to accept any criticism you may have about my code.

• Also ,despite the fact that I was looking to work in a team with @AbdullahKazi500 and @s-aldaihan I ended up doing this whole project alone and feel it is fair that I ask for the whole of the bounty. If you want to talk about the situation we can do so in the team discord that I linked earlier in the chat(which is empty)

[JordanAWS]

Hi @Gmontes01 we did a review of the PR and added comments. If you are able to make the requested modifications to the code by the end of today, you will win the bounty! Totally fine that you ended up working alone.

[Gmontes01]

@JordanAWS see how this works. I am submitting this before the end of 6/13 AoE time so hopefully I am still eligible for the bounty. I made the requested modifications and expanded the scope of the tests along with highlighting a new bug which would have gone otherwise unnoticed in the previous PR.

[JordanAWS]

Thanks @Gmontes01 ! Yes, since you submitted a PR with the main functionality before the June 13 deadline, you are indeed eligible for the bounty. We will likely do a few more review cycles between now and June 20th (the deadline to get the PRs from UnitaryHACK merged) :)

[christianbmadsen]

Now #111 has been merged. Thank you so much for your contribution @Gmontes01!