HT gradient - additional modes

[dtlics]

Context: Hadamard gradients method variants

Description of the Change: added support for different modes in hadamard gradient and implemented direct HT, reversed HT and reversed_direct HT

Benefits: more variants of HT + measurement grouping generates better efficiency for gradient estimation

Possible Drawbacks: for reversed methods, that is reversed HT and reversed_direct HT, the current version does not support circuits with multiple measurements. One will need to modify the processing_fn in how it aggregates the results so support this. For non-reversed methods, we aggregate for each measurement and the code work because the shape is N_G*M where N_G is the number of terms in the generator and M is the number of measurements. However, in reversed method, the shape is [N_1, ..., N_M], where for the i-th measurement, there are N_i gradient tapes. Different measurement has different number of tapes, and all the tape has only one measurement, so one does not need to aggregate across dimensions, just group neighboring ones would do.

Related GitHub Issues:

[albi3ro]

So for the failing test, we keep a hardcoded list of potential gradient keyword arguments here:

pennylane/pennylane/gradients/gradient_transform.py

Line 24 in 7bdf71b

SUPPORTED_GRADIENT_KWARGS = {

This was done as a patch to add validation to the QNode(qfunc, dev, ... , **gradient_kwargs) way of passing gradient keyword arguments and catching mistakes. Gladly, we will be getting rid of that in April, but for now, we will need to add "mode" to that hardcoded set.

[albi3ro]

When we are using the generator as a meausrement, do we still need to represent the observable as a linear combination of unitaries (paulis)?

Or could we technically just do:

mp = qml.expval(trainable_op.generator() @ qml.Y(aux_wire))

This might be a bit more general, and leaves interpreting the new observable up to the device.