Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Qubitunitary causes bug with complex matrix #541
Issue posted by user
Source code and tracebacks
TypeError Traceback (most recent call last)
~/dev/pennylane/pennylane/interfaces/autograd.py in call(self, *args, **kwargs)
~/anaconda3/envs/pennylane0.8/lib/python3.7/site-packages/autograd/tracer.py in f_wrapped(*args, **kwargs)
~/dev/pennylane/pennylane/qnodes/base.py in evaluate(self, args, kwargs)
~/dev/pennylane/pennylane/_qubit_device.py in execute(self, circuit, **kwargs)
~/dev/pennylane/pennylane/plugins/default_qubit.py in apply(self, operations, rotations, **kwargs)
~/dev/pennylane/pennylane/operation.py in parameters(self)
~/dev/pennylane/pennylane/operation.py in (.0)
~/dev/pennylane/pennylane/operation.py in evaluate(p)
~/dev/pennylane/pennylane/operation.py in check_domain(self, p, flattened)
TypeError: RX: Real scalar parameter expected, got <class 'numpy.complex128'>.
I think two things are happening here.
Ideally, we want the following behaviour:
However, when arrays are converted to variables, there is an issue. In the base QNode:
Due to NumPy casting rules, the presence of a single complex value will cause the entire array to become complex valued, even values that were originally real. This explains why this bug only affects circuits that contain
Question: is this a new issue, or has this always been present?
I think (3) is the best solution, alongside making it more clear to the user that arrays should always be auxiliary if they plan to do backpropagation/gradient computations.
I actually prefer solution (2), just have
Variable.positional_arg_values = list(_flatten(args)))
In that way, gates will still complain when the parameters are complex.
Note that passing arrays as parameters is totally within scope in pennylane (e.g.
(I'm using the primary/auxiliary parameter nomeclature here.)
The quantum circuits in PL are meant to be differentiable wrt. their primary parameters, which can always be treated as a flattenable nested sequence of real scalar values. So by design no complex values can appear as primary arguments. Furthermore, by design matrix-like parameters which are not differentiable should be auxiliary.
Note that this does not prevent passing real arrays as primary arguments (
I would not allow passing complex values to primary parameters even on the forward pass (evaluation only, no differentiation), since this is unnecessary and just confuses the concepts. If it works, the user will be twice as surprised when the differentation suddenly raises an error.
I think @johannesjmeyer 's idea might be good: use a list instead of an array. I thought