Fix perferred_lib

[to24toro]

Summary

The current code included list recursively by using list and I fixed the recursive part.

Details and comments

[to24toro]

kwargs are needed?

[DanPuzzuoli]

If we want to remove **kwargs the doc string for _numpy_multi_dispatch should be updated to explicitly state that the dispatching is only impacted by the type of args.

What issue did you run into that made you want to remove this? The only downside then is if for some reason we need to dispatch on one of the kwargs. At the moment though I guess we don't need this, so we could re-add it later if necessary.

[DanPuzzuoli]

Can you further explain the list recursion problem?

[to24toro]

Sorry for confusing you. It was not accurate. I looked into it in more detail. I guess it is an edge case when it occurs when registering list type to alias.
At DYNAMICS_NUMPY_ALIAS.infer_libs(args[0]) for second argument,
args[0] is interpreted as list because libs is not None at https://github.com/Qiskit-Extensions/arraylias/blob/275315c2244f4d1c6351642ed7f6ecad0bf7f847/arraylias/alias.py#L343.
if list type is not registered, libs is None and libs is defined at https://github.com/Qiskit-Extensions/arraylias/blob/275315c2244f4d1c6351642ed7f6ecad0bf7f847/arraylias/alias.py#L345 .

This error doesn't occur if we don't register list as type to alias.

My PR could fix this issue by deleting kwargs and changing args[1:] to *args[1:].

[DanPuzzuoli]

Ah I understand now. The follow up questions/comments I have are:

• Why do we need to register list again? Was it just for to_dense and to_sparse?
• Should we have a PR just for registering the new libraries "scipy_sparse" and "jax_sparse" (and "list" if necessary)? Maybe this change to _preferred_lib, as well as discussions about how to register list can be included in that PR. It might be beneficial to separate the type registering from the update to the models module.

[DanPuzzuoli]

@to24toro this is out of date and can be closed, correct?

[to24toro]

Yes. I closed.