[TAPE] Adds the CV parameter-shift tape

[josh146]

Context: Adds a new quantum tape, which implements the CV parameter-shift method.

Description of the Change:

The new tape is pretty much a direct port of the existing qml.qnodes.CVQNode to the new quantum tape paradigm.

Minor changes include:

• The CVParamShiftTape inherits from QubitParamShiftTape, since this avoids duplicating some logic (such as determining when to switch the parameter-shift rule to one that understands variances).

• New checks have been added to ensure the device supports PolyXP for second-order observables. If not, we raise a warning and fallback to finite differences. This fixes a bug where we cannot train on <N> using our remote hardware.

Benefits: n/a

Possible Drawbacks:

• While writing the tests, I discovered a bug that is present in the existing CVQNode: phase arguments return the incorrect derivative when forcing the second-order CV parameter-shift rule.

Related GitHub Issues:

[josh146]

@nquesada, I was wondering if you have any ideas to fix this? I think you might be the person who knows the logic best

[antalszava]

Just for my own understanding: how come this happens here?

[josh146]

If A is a 2D matrix, than we have to symmetrize it here (if it isn't symmetrized, than it won't correspond to a valid Hermitian observable).

Essentially, what we are doing here is A @ Z + Z @ A.T (since Z is always symmetric).

I believe this is the same as doing Z.T @ A @ Z / 2

[antalszava]

Oh right, thanks! When would A.ndim == 2 not be satisfied?

[josh146]

If the observable is first order in x and p, then A will be a 1D vector rather than a matrix. That should be the only other case --- alternatives could only occur if the developer doesn't follow the guidelines for heisenberg_rep

[antalszava]

Thank you! :) maybe worth leaving a comment? Such that it's clarified that having a first-order observable would be a possibility when e.g. the second-order param shift is enforced on a first-order observable. (as _transform_observable seems to be solely used by parameter_shift_second_order, which could be slightly misleading at first).

[antalszava]

Based on this docstring, would have thought it's an example for a fallback to finite differences, although it doesn't seem to be the case

[josh146]

It should be! Here, I am monkeypatching the rotation option to only specify grad_method="F". The CV tape should respect this, and return a grad method of "F" for that particular gate argument.

[josh146]

Note that one F parameter does not cause the entire circuit to require finite-difference---only that parameter gradient is computed using finite diff, the rest continue to use the parameter shift rule.

[antalszava]

Looks good to me, awesome @josh146! 💯 Thanks for answering my questions already 😊

[trbromley]

Looks awesome @josh146! Approved.