[BUG] Computing the matrix of an RX with a list as batched parameters raises an error

[AlbertMitjans]

Expected behavior

The following code returns the matrix:

>>> qml.RX([1, 2, 3], wires=0).matrix()
tensor([[[0.87758256+0.j        , 0.        -0.47942554j],
         [0.        -0.47942554j, 0.87758256+0.j        ]],

        [[0.54030231+0.j        , 0.        -0.84147098j],
         [0.        -0.84147098j, 0.54030231+0.j        ]],

        [[0.0707372 +0.j        , 0.        -0.99749499j],
         [0.        -0.99749499j, 0.0707372 +0.j        ]]], requires_grad=True)

Actual behavior

The following code raises an error:

>>> qml.RX([1, 2, 3], wires=0).matrix()
TypeError: unsupported operand type(s) for /: 'list' and 'int'

Additional information

An easy fix would be to cast the input parameters to a tensor object.

Source code

No response

Tracebacks

No response

System information

Name: PennyLane
Version: 0.29.0.dev0
Summary: PennyLane is a Python quantum machine learning library by Xanadu Inc.
Home-page: https://github.com/XanaduAI/pennylane
Author:
Author-email:
License: Apache License 2.0
Location: /opt/homebrew/lib/python3.11/site-packages
Requires: appdirs, autograd, autoray, cachetools, networkx, numpy, pennylane-lightning, requests, retworkx, scipy, semantic-version, toml
Required-by: PennyLane-Lightning

Platform info:           macOS-13.0.1-arm64-arm-64bit
Python version:          3.11.0
Numpy version:           1.23.5
Scipy version:           1.9.3
Installed devices:
- default.gaussian (PennyLane-0.29.0.dev0)
- default.mixed (PennyLane-0.29.0.dev0)
- default.qubit (PennyLane-0.29.0.dev0)
- default.qubit.autograd (PennyLane-0.29.0.dev0)
- default.qubit.jax (PennyLane-0.29.0.dev0)
- default.qubit.tf (PennyLane-0.29.0.dev0)
- default.qubit.torch (PennyLane-0.29.0.dev0)
- default.qutrit (PennyLane-0.29.0.dev0)
- null.qubit (PennyLane-0.29.0.dev0)
- lightning.qubit (PennyLane-Lightning-0.27.0)

Existing GitHub issues

• [X] I have searched existing GitHub issues to make sure the issue does not already exist.

[albi3ro]

@dwierichs Do we allow batching with lists? Should we check this earlier on?

[dwierichs]

No, we do not allow this currently, and most operations will raise an error when used with batching with lists. I think we have the following options:

• allow lists by casting them to tensors. I'm not sure how easy this will be to keep consistent for all interfaces. Another question would be whether to do this casting at instantiation or within the particular methods (probably the former?). Finally, some operations might require list arguments without batching, so that the casting would have to be deactivated for some operations.
• keep disallowing lists for batched inputs, but implement a test that raises a warning/error (instantiating might be fine, matrix most likely is the problematic part). Again there would be multiple options where to check for this.
• add documentation to mention lists not being allowed, but not changing any code.

What are use cases for batching with lists? Do we expect the restriction to batching with tensor_like objects to be severe?

[albi3ro]

I would vote explicitly not supporting lists.