Fix qml.grad so that the returned gradient always matches the cost function return type if only a single argument is differentiated

[josh146]

Context:

I realised yesterday that autograd.grad behaves differently depending if the argnum argument is a sequence or an integer:

>>> import autograd
>>> from autograd import numpy as np
>>> autograd.grad(np.sin, argnum=0)(0.6)
0.8253356149096783
>>> autograd.grad(np.sin, argnum=[0])(0.6)
(array(0.82533561),)

We never take this into account in PennyLane, which can lead to gradients often being returned as tuple of size 1.

Description of the Change:

• If the inferred argnum argument is a sequence of length 1, only the contained integer is passed to autograd.grad.

Benefits:

• The return of qml.grad should now always match the return type of the function being differentiated.

• A lot of superfluous [0] could be removed from the tests (e.g., qml.grad(circuit)(x)[0])

Possible Drawbacks:

• The optimizers have to add in the redundant tuple where needed so that the gradient remains iterable. But this is a easy change, and leads to an intuitive UI, so maybe better?

• Some of the demos might need to be updated to remove unneeded [0] after gradient computations. But I think very few demos actually show the gradients.

Related GitHub Issues: n/a

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.74%. Comparing base (812e9d4) to head (de65756).
Report is 2658 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1067   +/-   ##
=======================================
  Coverage   97.74%   97.74%           
=======================================
  Files         153      153           
  Lines       11584    11590    +6     
=======================================
+ Hits        11323    11329    +6     
  Misses        261      261           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chaserileyroberts]

We have to turn grad into a tuple because we're reversing what we did to argnum earlier, right?

[josh146]

Yep, the optimizer logic currently assumes grad is always iterable with respect to argument number.

I figured, easier to leave this logic intact and simply re-tuple the grad

[chaserileyroberts]

Agreed.