Handling incompatible/nonsensical SINDy problems

[Jacob-Stevens-Haas]

My overall research proposal revolves around incorporating the differentiation/smoothing step of SINDy into the regression objective, meaning that it will entirely skip the differentiation step. That probably means that it should subclass SINDy, rather than working with a special feature library that limits compatibility.

@znicolaou @akaptano , I wanted to ask if you think something similar made sense for other forms of SINDy, which natively have some incopatability with other feature libraries? The weak method might benefit from this by leaving the integrate step of the process after fitting the feature libraries, which could allow the weak method to work with any of the other feature libraries (e.g. the TensorLibrary issue) and offload the work of dealing with custom functions passed directly to WeakPDELibrary. I'm not as familiar with the requirements for Trapping or SINDy-PI, but are they fully compatible with other libraries/differentiation methods?

I'm giving a talk to the group on May 8th, and hoping to generate some discussion on what the next set of breaking changes should be. I think some foresight around this question might help design a better API for the first stable 2.0 release.