Description
Is your feature request related to a use case or problem? Please describe.
When working on #7048, was surprised that unitary(val)
and apply_unitary(val, args)
didn't accept raw numpy unitaries for val
. This made it necessary to special case a couple isinstance(np.ndarray)
checks in the consumers of those functions. There is also an already-existing redundant function in apply_mixture
that can be removed if apply_unitary
can accept raw numpy unitaries. If accepted, this could be a good first issue for someone.
Describe the solution you'd like
I started this for apply_unitary
in #7039, but closed the PR because a) I think it's a maintainer decision as to whether the feature is desired, how large the scope should be, and whether it can be delivered incrementally or should go all-at-once, and b) I think it would be a good first issue for someone to learn about quantum operators in general, and cirq's implementation of protocols in particular.
As mentioned in the closing comment #7039 (comment), the scope is open-ended.
Closing for now. Seems like if we do this, then we should also do
unitary
andhas_unitary
. Which, then may as well domixture
andkraus
series, maybeact_on
, and whatever else comes up too. Support raw Python arrays? Sympy?....
[optional] Describe alternatives/workarounds you've considered
Duplicate code, instanceof
checks.
[optional] Additional context (e.g. screenshots)
As part of this, I noticed the protocols have different techniques. Some loop through an array of strategies, others are more imperative. Some use dynamic invocations of the fallback strategies, whereas others call the fallback protocols directly. It'd be good to improve consistency in these when working through them.
What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I'm not really blocked by it, it is a suggestion based on principle