Cast gates to dense matrices in optools

[Timo1104]

Description of changes

Minor change: in optools.entanglement_fidelity, accept both arrays and gates for the a and b arguments. The arguments are cast to (dense) arrays within the function scope.

Perform similar casting in other functions, that call a.shape.

Motivation

See also #406.

Since some update (cannot pinpoint which exactly), this casting was not done anymore, neither within optools.entanglement_fidelity, nor in any of the functions calling this one.

I've chosen to cast to dense array within optools.entanglement_fidelity, rather than before calling this function, for two reasons:

• It keeps the number of changes as small as possible;
• It provides a more consistent interface across optools. Other functions (such as average_gate_fidelity, which calls entanglement_fidelity) accept arrays or gates. Hence, I'm of the opinion that casting to array within entanglement_fidelity is the more consistent choice. Alternatively, casting can be done before calling it, but (IMO) it's more consistent to then also do that for the other metrics functions defined in optools. I'm okay with either way, but this seems the simpler and less backwards-breaking solution, but I'm happy to implemetn otherwise if required.
• It resolves an error in for example average_gate_fidelity, which states in the docstring that it accepts arrays or gates for a and b, but directly passes a and b to entanglement_fidelity, leading to an error.
• Prevents errors on calling a.shape on gates that do not have the shape attribute (such as ComposedOps)

[sserita]

Will approve once the contextlib calls are swapped out for LinearOperator checks.

Thanks for your PR!

[sserita]

Can we change the contextlib.suppress calls to an isinstance(_, LinearOperator) instead?

It's more pyGSTi style to check for the base class that provides the used API than a blanket error suppression.

[Timo1104]

Of course! I'm more used to EAFP-style programming, but happy to accomodate LBYL, too :) Just pushed the changes!

[sserita]

Thanks Timo. There's definitely arguments to be made that EAFP is a nicer way to go, but it's appreciated that you're willing to conform to current style :)

Looks good, thanks for the contribution!