You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current implementation when one defines an estimator for a non-leaf, one can use the inherited_params to pass input parameters down to the component's descendants. However, it would be nice if it was possible to pass down functions of input parameters as well.
For example, the QROM estimator must take the input parameters and . However, the parameter that one wants to pass down to the select subcomponent is actually . This is can be currently achieved by passing down both and and having select subroutine perform the necessary division. But since select shouldn't have any concept of or , this is not an ideal solution.
This issue is to implement support of such parameter inheritance.
We will probably have to change the current inherited_params interface. Currently the format is a dictionary with the keys as the input parameter being inherited and the value as a list of places it will be inherited. However, I think this should instead be changed to a dictionary where the key is the parameter function expression (e.g. N/lambda) and the value be a list of locations of inheritance.
I think the best way to do this will be to introduce a function that implements any such function over the inherited parameters and then have the inheritor's function merged into this, thereby producing a new function over the parameters input to the expression.
In the current implementation when one defines an estimator for a non-leaf, one can use the inherited_params to pass input parameters down to the component's descendants. However, it would be nice if it was possible to pass down functions of input parameters as well.
For example, the QROM estimator must take the input parameters and . However, the parameter that one wants to pass down to the select subcomponent is actually . This is can be currently achieved by passing down both and and having select subroutine perform the necessary division. But since select shouldn't have any concept of or , this is not an ideal solution.
This issue is to implement support of such parameter inheritance.
We will probably have to change the current
inherited_params
interface. Currently the format is a dictionary with the keys as the input parameter being inherited and the value as a list of places it will be inherited. However, I think this should instead be changed to a dictionary where the key is the parameter function expression (e.g.N/lambda
) and the value be a list of locations of inheritance.I think the best way to do this will be to introduce a function that implements any such function over the inherited parameters and then have the inheritor's function merged into this, thereby producing a new function over the parameters input to the expression.
(Originally by @sammorley-short )
The text was updated successfully, but these errors were encountered: