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
This issue is meant to summarize the discussion that was held during today's meeting with @vnmabus and Alberto Suárez on implementing binary operations between FData objects and other callables, and unary operations on FDataBasis objects.
The motivation to tackle this issue has emerged from questioning whether to define scores/distances between different FData types. #458 requested some of the functionality that is discussed here (only for binary operations between FDataGrid and other python callables).
Desired operations
Operations not listed have also been discussed. This list only contains the operations that we want to have in the package.
It was not explicitly discussed, but __pow__ should probably be considered as an operation to implement in most of these cases.
Unary operations on FDataGrid and FDataIrregular
Already implemented. This functionality needs to be properly tested.
Binary operations (sum, sub, mul, div) for FDataGrid and FDataIrregular
f1 and f2 are measured at the same points (already implemented).
Operations discussed that we decided not to implement (yet)
FDataBasis operations
Proposal: project the result of the operation on the basis.
Unary operations (f1: FDataBasis)
Decided against:
Not natural.
The user can manually project.
Has not been requested.
[sum, sub] (f1: FDataBasis, f2: function)
f2 is not an FData and can be evaluated at every point of f1's domain.
Decided against: same reasoning as unary operations for FDataBasis.
[sum, sub] (f1: FDataBasis, f2: FDataBasis)
Same basis: already implemented.
Different bases (not to be implemented yet): special cases in which the bases can be made compatible (by taking the "minimum base that contains both") --- Ramsay FDA.
BSplineBasis.
FourierBasis (same period).
Score (y_true: FData, y_pred: FData)
Proposal: when y_true and y_pred are of different FData subclasses, convert y_pred to the type of y_true (if compatible) and then compute the score.
Decided against: better to be explicit than implicit. Let the user do the conversion if they need it.
The text was updated successfully, but these errors were encountered:
Motivation
This issue is meant to summarize the discussion that was held during today's meeting with @vnmabus and Alberto Suárez on implementing binary operations between FData objects and other callables, and unary operations on FDataBasis objects.
The motivation to tackle this issue has emerged from questioning whether to define scores/distances between different FData types. #458 requested some of the functionality that is discussed here (only for binary operations between FDataGrid and other python callables).
Desired operations
Operations not listed have also been discussed. This list only contains the operations that we want to have in the package.
It was not explicitly discussed, but
__pow__
should probably be considered as an operation to implement in most of these cases.Unary operations on FDataGrid and FDataIrregular
Already implemented. This functionality needs to be properly tested.
Binary operations (sum, sub, mul, div) for FDataGrid and FDataIrregular
[sum, sub, mul, div] (f1: FDataGrid | FDataIrregular, f2: function)
[sum, sub, mul, div] (f1: FDataGrid | FDataIrregular, f2: FDataBasis)
[sum, sub, mul, div] (f1: FDataGrid, f2: FDataGrid)
[sum, sub, mul, div] (f1: FDataIrregular, f2: FDataIrregular)
Operations discussed that we decided not to implement (yet)
FDataBasis operations
Proposal: project the result of the operation on the basis.
Unary operations (f1: FDataBasis)
Decided against:
[sum, sub] (f1: FDataBasis, f2: function)
Decided against: same reasoning as unary operations for FDataBasis.
[sum, sub] (f1: FDataBasis, f2: FDataBasis)
Score (y_true: FData, y_pred: FData)
Proposal: when y_true and y_pred are of different FData subclasses, convert y_pred to the type of y_true (if compatible) and then compute the score.
Decided against: better to be explicit than implicit. Let the user do the conversion if they need it.
The text was updated successfully, but these errors were encountered: