Implement SparsePauliOp.assign_parameters

[mrossinek]

What should we add?

#8620 added support for Parameter objects to be used inside of SparsePauliOps, porting this functionality from opflow to quantum_info and paving the way for a switch of the algorithms and application modules to be using purely quantum_info in the future.

However, once key functionality for this to be useful is still missing; and that is the implementation of SparsePauliOp.assign_parameters. Without it, there is no convenient way of actually using a parameterized SparsePauliOp instance.

[ikkoham]

SparsePauliOp can have ParameterExpression as coefficients, but it does not assume that it is complex | ParameterExpression. It will accept any type of coefficient.

I am thinking that the handling of binding is user’s job or Parameter module’s job. I don’t think at least it is SparsePauliOp's job now.

We may still have a helper function in Parameter, but I don’t want to make a method that assumes that it has a Parameter. What should we do if it’s symply.Symbol as a coefficient? There can be other types. SparsePauliOp should not cover those all cases, but should be handled by the user.

Example of helper function I am thinking:

def get_parameters(array) -> ParameterView:
    ret = set()
    for a in array:
        if isinstance(a, ParameterExpression):
            ret |= a.parameters
    return ParameterView(ret)

def assign_parameters(array, parameter_values):
    if isinstance(parameter_values, list):
        parameter_values = dict(zip(get_parameters(array), parameter_values))
    for i, a in enumerate(array):
        if isinstance(a, ParameterExpression):
            for key in a.parameters & parameter_values.keys():
                a =  a.assign(key, parameter_values[key])
            if not a.parameters:
                a = complex(a)
            array[i] = a
    return array

spo = SparsePauliOp(["II", "XZ", "II"], np.array([Parameter("a"), Parameter("b"), 3+1j]))
assign_parameters(spo.coeffs, [2, 9])

Added: the order of parameters is undefined. I'm not sure if the user want to sort.

[mrossinek]

Alright, thank you! 👍

Feel free to close this issue if you feel like this resolves it. I am open to whether or not this functionality should be added.

[woodsp-ibm]

When opflow was done with Parameter support we had consistency in the way the object supported Parameters with the same the methods as a parameterized circuit for the parameterized operator. My take is that it would nice to have the same support here with the Parameter support/objects Terra has. If you are allowing other types as coeffs then I agree the onus is on an end user. But for Parameter support my take would be to have the SparsePauliOp support it for consistency and ease of end user use.

[Cryoris]

I also think it would be good to have proper support of Qiskit's Parameter objects in the SparsePauliOp, as it is replacing how we used parameterized operators in Opflow. In several algorithms (e.g. QBMs in ML or time-evolution with time dependent Hamiltonians) we would need to assign parameters to the operators.

As Steve said already, we of course don't support binding any variable type but since the Parameter is Qiskit native I would expect support for that 😄 Also, the parameters should be bound in the same order as in the circuit 🙂

[ElePT]

Issue resolved by #9796.