Add quantum phase estimation template #1095
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1095 +/- ##
=======================================
Coverage 97.74% 97.74%
=======================================
Files 154 155 +1
Lines 11734 11753 +19
=======================================
+ Hits 11469 11488 +19
Misses 265 265
Continue to review full report at Codecov.
|
…ane into quantum_phase_estimation
There was a problem hiding this comment.
Looks great! 🎉
I'm slightly worried that this implementation is overfitting for the quantum monte carlo application and may not be the optimal way of implementing the template for such a widely-used routine as quantum phase estimation.
The tests are great, but perhaps they could benefit from also testing correctness for different phases and unitaries
|
|
||
|
|
||
| @template | ||
| def QuantumPhaseEstimation(unitary, target_wires, estimation_wires): |
There was a problem hiding this comment.
It would be good to discuss a bit more whether we want to pass the unitary or its generator, i.e., the Hamiltonian. I'm a bit afraid that we're narrowing the scope to how QPE is used in quantum Monte Carlo. But QPE is used in a lot of places, for example in versions of Shor's algorithm, for preparing approximate ground states of Hamiltonians, and more.
Maybe we can compile a list of applications of QPE and that can help guide how best to create a template around it? 🤔
There was a problem hiding this comment.
I really like the suggestion about supporting input Hamiltonians, and yes you're right I hadn't been thinking so much in that direction.
So we have the two options for input:
- unitary, eventually as a circuit
- Hamiltonian, input as a
qml.Hamiltonian, and evolution timet, and we can do exp(2 pi i H t).
For me, the best option would be to have two separate templates, given that the inputs and how they will be dealt with are quite different. In option 2, we'd need to use ApproxTimeEvolution, whereas option 1 would directly apply controlled versions of the circuit. In either case, we need access to a qml.control() transform.
For now, we've done option 1 with a matrix-based input. I'm not sure if it's worth supporting a matrix-based version of option 2, since one could just calculate the matrix exponential themselves. On the other hand, users typically have access to a qml.Hamiltonian and I couldn't work out how to get the matrix version of that! But with qml.Hamiltonian I can only see how to do it with qml.control().
So overall, I totally agree, but think we'd be better to wait for supporting functionality to come online.
One question might be what we call the two options, e.g.,
QuantumPhaseEstimationorUnitaryPhaseEstimation?HamiltonianPhaseEstimation?
There was a problem hiding this comment.
I'm happy to wait for more functionality to come online before supporting Hamiltonian inputs. I'm not sure if having two templates is preferable to supporting to different types of arguments, but we can discuss that in the future. Re names: let's also discuss in the future. I like keeping QuantumPhaseEstimation for this form of the template
|
|
||
|
|
||
| @template | ||
| def QuantumPhaseEstimation(unitary, target_wires, estimation_wires): |
There was a problem hiding this comment.
I really like the suggestion about supporting input Hamiltonians, and yes you're right I hadn't been thinking so much in that direction.
So we have the two options for input:
- unitary, eventually as a circuit
- Hamiltonian, input as a
qml.Hamiltonian, and evolution timet, and we can do exp(2 pi i H t).
For me, the best option would be to have two separate templates, given that the inputs and how they will be dealt with are quite different. In option 2, we'd need to use ApproxTimeEvolution, whereas option 1 would directly apply controlled versions of the circuit. In either case, we need access to a qml.control() transform.
For now, we've done option 1 with a matrix-based input. I'm not sure if it's worth supporting a matrix-based version of option 2, since one could just calculate the matrix exponential themselves. On the other hand, users typically have access to a qml.Hamiltonian and I couldn't work out how to get the matrix version of that! But with qml.Hamiltonian I can only see how to do it with qml.control().
So overall, I totally agree, but think we'd be better to wait for supporting functionality to come online.
One question might be what we call the two options, e.g.,
QuantumPhaseEstimationorUnitaryPhaseEstimation?HamiltonianPhaseEstimation?
|
|
||
|
|
||
| @template | ||
| def QuantumPhaseEstimation(unitary, target_wires, estimation_wires): |
There was a problem hiding this comment.
I'm happy to wait for more functionality to come online before supporting Hamiltonian inputs. I'm not sure if having two templates is preferable to supporting to different types of arguments, but we can discuss that in the future. Re names: let's also discuss in the future. I like keeping QuantumPhaseEstimation for this form of the template
Context:
Adds a QPE template.
Description of the Change:
Added a new template to the subroutines folder.
Benefits:
Users can now perform QPE!
Possible Drawbacks:
QPE is only available in matrix format. Hopefully that should be clear by the documentation.