thanks for creating this awesome library! I have a comment on the [Operators] inheriting from the class function:
The way operators are created is slightly odd to me:
When you declare an operator in PEPit you declare it as a child of the class function, which is a bit weird since not every operator is the gradient of a function.
I guess it is a hack to make the library work easily since it has been originally developed on functions. However, some use cases are slightly disturbing:
In the constrained case, [some examples] consider the sum between the indicator and the operator function but the function induced by the operator does not always exist. What is meant there is that we are looking for 0 to be in the subdifferential of this sum.
Calling F.gradient is slightly odd to me for the same reason: F is already the operator to be called and F.gradient could be considered to be the Jacobian of the operator.
Maybe one way to fix that would be to reverse the legacy (function would be a child of the Class Operator). But I understand that it may require to rethink the whole architecture of the library which may be challenging.
Hello,
thanks for creating this awesome library! I have a comment on the [Operators] inheriting from the class function:
The way operators are created is slightly odd to me: When you declare an operator in PEPit you declare it as a child of the class function, which is a bit weird since not every operator is the gradient of a function.
I guess it is a hack to make the library work easily since it has been originally developed on functions. However, some use cases are slightly disturbing:
Maybe one way to fix that would be to reverse the legacy (function would be a child of the Class Operator). But I understand that it may require to rethink the whole architecture of the library which may be challenging.