Is your feature request related to a problem? Please describe.
This is a problem that occurred in an application. Sometimes the input data has multiple coordinates of very different scales. Ran into some data where $x_1(t)$ is $\mathcal O(10^{-2})$ and $x_2(t)$ is $\mathcal O(10^2)$. Fitting most optimizers on a SINDy model with polynomial terms tends to reject all terms on $\dot x_1$ because they're all so small
Describe the solution you'd like
Some sort of prenormalization and post normalization of coordinates in the SINDy model.
Alternatives
User is responsible for normalizing data.
Additional context
Several challenges:
Simplifying the expression is hard, since extracting the normalization constant from the function library into the coefficients is only straightforwards (and indeed, possible) for polynomial library.
It also may interact with differentiation methods in complicated ways.
Conclusion:
This seems a case of the general issue where we leave it up to the user to make sure that the data is in the right coordinate system. The only other generic approach I've seen to this is autoencoders. The generality, as well as the mathematical challenges mean it's probably best to do nothing for now (hence the wontfix label), but planting a flag for future discussion about coordinate system input data.
Maybe we need a research label for people driving by and looking for paper topics that we don't have attention to address?
Is your feature request related to a problem? Please describe.
This is a problem that occurred in an application. Sometimes the input data has multiple coordinates of very different scales. Ran into some data where $x_1(t)$ is $\mathcal O(10^{-2})$ and $x_2(t)$ is $\mathcal O(10^2)$. Fitting most optimizers on a SINDy model with polynomial terms tends to reject all terms on $\dot x_1$ because they're all so small
Describe the solution you'd like
Some sort of prenormalization and post normalization of coordinates in the SINDy model.
Alternatives
User is responsible for normalizing data.
Additional context
Several challenges:
Conclusion:
This seems a case of the general issue where we leave it up to the user to make sure that the data is in the right coordinate system. The only other generic approach I've seen to this is autoencoders. The generality, as well as the mathematical challenges mean it's probably best to do nothing for now (hence the
wontfixlabel), but planting a flag for future discussion about coordinate system input data.Maybe we need a research label for people driving by and looking for paper topics that we don't have attention to address?