Support AmplitudeEncoding on hardware

[johannesjmeyer]

Right now, the function AmplitudeEncoding is purely a wrapper around QubitStateVector. This is somewhat dissatisfying because it forces the user to basically transform his data into a quantum state himself.

We could probably beef up this function a bit -- by allowing a feature vector that has less than 2^n elements (we would then pad them with zeros) and allowing that the squares don't sum to 1 (we would then normalize the vector). What are your thoughts?

[AroosaIjaz]

I agree, that would be a nice addition to this function. Thanks, @johannesjmeyer :) This will also go hand-in-hand with the concepts section on this topic (PR #216 ). I will work on this asap.

[mariaschuld]

Carsten Blank (who helped with the IBM plugins) has qiskit code for an implementation of AmplitudeEmbedding using gates - and not a simulation hack - based on a paper from Mottoennen et al: https://github.com/carstenblank/dc-qiskit-algorithms/blob/master/dc_qiskit_algorithms/M%C3%B6tt%C3%B6nenStatePrep.py

This would be cool to include, i.e. with a flag that chooses if one uses 'QubitStateVector' or the actual circuit for the task.

He kindly agreed that we can just rewrite the code as a PennyLane Template!

[josh146]

He kindly agreed that we can just rewrite the code as a PennyLane Template!

This sounds awesome @mariaschuld; this would allow AmplitudeEmbedding to work on hardware! We had a request for this the other day (https://discuss.pennylane.ai/t/amplitudeembedding/169/8)

[nquesada]

Would it make more sense to implement directly MöttönenStatePrep in QubitStatePrep and have AmplitudeEncoding call it?

[josh146]

Would it make more sense to implement directly MöttönenStatePrep in QubitStatePrep and have AmplitudeEncoding call it?

I think this is a very good question, that doesn't have a clear answer. Some plugins (such as Qiskit) support arbitrary state preparation, and have their own code for decomposition. Others, such as Forest, don't, so would benefit from having this in PennyLane.

At the same time, we don't currently have a good framework to allow both options in PennyLane. Ideally, it would work as follows:

1. User creates a QNode which includes QubitStateVector

2. The device it is registered to communicates to the QNode which operations it supports.

3. If it supports QubitStateVector (e.g., IBM), the queue remains as is

4. If it doesn't support QubitStateVector, the QNode instead modifies the queue by calling (for example) QubitStateVector.decompose() which uses the Mottonen result to decompose it into other PennyLane operations.

This is a similar approach to what we do in Strawberry Fields. Thoughts?

[co9olguy]

Honestly, it sounds like something that would best fit within the plugins themselves, since it is their responsibility to translate top-level circuits into hardware-compatible circuits.

If included as part of core PennyLane, we need to have a way to make clear to the user when there is a decomposition happening behind the scenes. If their circuit gives completely different results on two different hardwares, we want to make it as clear as possible how the execution might be different.

[josh146]

I just woke up and had the exact same thought @co9olguy, but you vocalised it before I had a chance 😆 This is something we should add to the plugins, which are designed to map PL operations to specific hardware frameworks.

[mariaschuld]

Also agree that the implementation of QubitStateVector is up to the plugins, but would still like to see a proper state preparation routine in the Embedding. The reason is that for all practical purposes we need to prepare the state on a subregister of qubits, which QubitStateVector cannot do (at this stage).

[johannesjmeyer]

Maybe it would be a good idea to have the MöttonenStatePrep somewhere (maybe in the templates) so that if you develop a plugin that has no direct support for state preparations you would not have to cook that code up for youself but you can then just call the MöttonenStatePrep (e.g. for the forst plugin).