Closed RolandMacDoland closed 4 hours ago
@kaosmicadei wdyt ?
The position of the arguments is only for internal use. The idea is to use the class method constructor Expression.quantum_operator
, which already implements the support as a positional argument.
But this is an advanced user feature used to define new operators. Regular users are not required to go that deep.
About the indexation of the arguments, it’s the standard procedure with S-expression and AST.
Moving the support to the attribute also changes the mean of it. The attributes were designed to hold metadata related to symbolic simplification.
This can be rethought to become more pythonic but can potentially make the symbolic manipulation more complex.
The position of the arguments is only for internal use. The idea is to use the class method constructor
Expression.quantum_operator
, which already implements the support as a positional argument.But this is an advanced user feature used to define new operators. Regular users are not required to go that deep.
About the indexation of the arguments, it’s the standard procedure with S-expression and AST.
Moving the support to the attribute also changes the mean of it. The attributes were designed to hold metadata related to symbolic simplification.
This can be rethought to become more pythonic but can potentially make the symbolic manipulation more complex.
Yeah OK I see. It simply felt a bit fragile to see that indexing but effectively this is enforced by the Expression
constructors.
Support
is currently anarg
in the quantum op expression creation and is accessed through indexingself
. This is fragile as it presupposes the user to pass arguments in an defined order which is not guaranteed nor enforced in our parameters list. Possible solutions:Support
a positional argumentSupport
an attribute that can be key accessed