teleportation notebook

[sarsid]

Adds an example notebook for quantum teleportation which works with the new code in PR ([https://github.com/qutip/qutip/pull/1274]).

[review-notebook-app[bot]]

Check out this pull request on 

Review Jupyter notebook visual diffs & provide feedback on notebooks.

---

Powered by ReviewNB

[BoxiLi]

Thanks, @sarsid for the notebook! I left a few quick comments. Measurement functions look good.

I'm wondering, do you plan to make it a notebook for the measurement class or for teleportation?

• If it is all about teleportation then we could introduce it in more details.
• If it is going to be a notebook for measurement, then starting with what is the quantum measurement, introducing our class/methods interface and ending with teleportation as an example might be a better order for the demonstration.

[BoxiLi]

Just got an idea. Since we are doing simulation, we actually have access to the quantum state (instead of only the measurement result). Therefore, we can compare the state q0 and the state after the teleportation! This will be more convincing evidence that the teleportation is successful because measuring the amplitude does not reveal the phase.

[sarsid]

Just got an idea. Since we are doing simulation, we actually have access to the quantum state (instead of only the measurement result). Therefore, we can compare the state q0 and the state after the teleportation! This will be more convincing evidence that the teleportation is successful because measuring the amplitude does not reveal the phase.

How can we compare the state directly, do you mean by writing in terms of tensor product, in which case I'm not sure how the global phase will be relevant. We have to keep in mind that the other two qubits can have arbitrary results in the teleportation circuit, right ?

[sarsid]

Thanks, @sarsid for the notebook! I left a few quick comments. Measurement functions look good.

I'm wondering, do you plan to make it a notebook for the measurement class or for teleportation?

• If it is all about teleportation then we could introduce it in more details.
• If it is going to be a notebook for measurement, then starting with what is the quantum measurement, introducing our class/methods interface and ending with teleportation as an example might be a better order for the demonstration.

Do you think we should have a separate notebook that addresses measurement explicitly or it can be covered in the documentation guide instead? I am not sure if measurement in the circuit itself merits a separate notebook ?

[BoxiLi]

How can we compare the state directly

Well, we can trace out the ancilla qubits (qutip.ptrace) after they are measured, leaving only the target qubit.

To compare, we can either calculate the fidelity between the input state and the output state or compare the sate directly. In the first case, the global phase doesn't matter. In the second, if the state is in ket vector form, one can force the first element to be real (vector /= np.angle(vector[0]) and fix the global phase thereby.

[BoxiLi]

Do you think we should have a separate notebook that addresses measurement explicitly or it can be covered in the documentation guide instead? I am not sure if measurement in the circuit itself merits a separate notebook ?

Maybe you are right, it can be covered in the documentation guide. Sometimes there can be some overlap between the user guide and the notebooks. You can do whichever you find better.

[BoxiLi]

If you like, you can also add your name and email.

[sarsid]

@BoxiLi, I made the above suggested changes. I just realized, however, that the circuit display functionality is a little broken due to the addition of classical registers but that will require a bit more work than just hacking around the current function. I think I'll fix it in a future PR (more comprehensively). Otherwise, the notebook should be ready to merge.

[BoxiLi]

I see, yes, we need to replace classical wires with double lines. Would be great if we can fix it in further PR. @nathanshammah would you also like to have a brief look at the notebook?

[BoxiLi]

@sarsid, I have a question about circuit.run. I'm a bit confused by what circuit.run returns. It returns (state, probability) Why is there a probability?

[sarsid]

@sarsid, I have a question about circuit.run. I'm a bit confused by what circuit.run returns. It returns (state, probability) Why is there a probability?

Since we are running exact circuit computation, when we measure on a particular qubit we can also find the probability of the measurement. If we just multiply them (they are independent) we can observe the probability of getting a particular outcome (there are only 2^n outcomes when we do exact measurement if there are n measurement gates). This is also convenient when calling run in run_statistics.

[BoxiLi]

Thanks @sarsid , I get it now. Though I'm still wondering if this probability could be misleading in some cases. I posted a discussion here, since it is unrelated to the notebook.

[sarsid]

Thanks @sarsid , I get it now. Though I'm still wondering if this probability could be misleading in some cases. I posted a discussion here, since it is unrelated to the notebook.

I think I have addressed this now with the new Result class, it has the probability in it but you can instead just grab states by doing Result.get_states(). Maybe you want to review the Result and Simulator. PR first (I'm still left with adding tests on that buy API structure is good to go) before merging this notebook.