Closed antalszava closed 2 years ago
@dwierichs any thoughts on the reason for the issue and/or if it could be a potentially significant use case? :thinking:
The problem here is not that there are multiple zero-shift terms, it is that there are no nonzero-shift terms :) Terms with the same shift (and multiplier) are actually grouped together before creating the tapes.
This bug happens because the code inherently assumes that a non-zero shift will be needed to obtain the derivative (this assumption is not used for Hamiltonian parameters, just for operations). For all operations I know this makes sense, but maybe there are some for which it doesn't. It would not be hard to change this, should I do so? Or would we prefer a warning? I would not see any silent bug that would result from the former, i.e. just allowing derivatives with non-zero shifts only. In particular, this would also allow "dummy" recipes without any terms at all, for whatever reason one might want to use those :grin:
Frankly, I think any type of handling of the case (either changing the behaviour and/or having a warning) could be nice. I suspect it's not going to be a case widely stumbled upon, though it could confuse some users because it raises an error.
Just making sure: The number of tapes will be 2*num_ops_standard_recipe+int(len(ops_with_custom_recipe)>0)
, right? 2 shifted evaluations per "normal" recipe operation and one global one if at least one op has the custom recipe.
Also: This recipe doesn't work, so the last assertion should not go through, correct? :)
Expected behavior
Any custom gradient recipe executes without errors.
Actual behavior
An indexing error is raised for a gate with the custom recipe of
[[-1e7, 1, 0], [1e7, 1, 0]]
.Additional information
No response
Source code
Tracebacks
System information
Existing GitHub issues