Pysindy wider research community goals and policies

[Jacob-Stevens-Haas]

The research community has reached out about 1/mo this summer to contribute either examples (#211), new methods (#215), or related research (#249). These have prompted a few questions about how pysindy should incorporate the broader research community:

• Linking repositories of existing SINDy research code that aren't yet linked (e.g. https://github.com/dynamicslab/langevin-regression)
• Keeping track of related research that may or may not have code repos (see Github traffic and PySINDy paper tracking #245)
• SINDy namespace (such as SINDy-PI, SINDy-E, SymINDy, and I'm sure there's more). E.g. If I wanted to add Kalman smoothing to SINDy and call it SINDy-K, but the above-linked repo chose the name SINDy-K instead of "Langevin Regression" (because one of their steps, the Fokker Planck equation, is also called the Kolmogorov Forwards Equation), how would I know "SINDy-K" was already taken?
• Incorporating SINDy research repositories into pysindy vs 3rd party packages. E.g. Is it possible/desirable to make SymINDy fit the SINDy API? It looks like a CompositeLibrary class would be able to handle the myspring example of @matteoettam09. I wonder whether they would also be able make GeneticOptimizer class using DEAP. This is similar to the community-added MIOSROptimizer class in Clean up MIOSR #219, where we raised the question whether API-compatible classes should be their own packages or PR'd into pysindy.
• pre-publication code. E.g. @wesg52 did thorough research incl. a full-length journal paper before submitting a PR. Would we still have accepted the PR without that level of rigor and explanation? If not, does that same standard apply inside dynamicslab, e.g. to my own Save DifferentiationMethod smoothed values #244, which I plan to use for publication in the future? We're obviously not as mature as scipy, but for ref, here's their inclusion criteria

In general, my thoughts are:

• Make it easier for people to use pysindy both for basic and applied research
• De-conflict, but avoid gate-keeping
• Limit the load on maintainers (e.g. External examples #227, Add helpful pre-commit checks and CI Documentation build step #229 )

Sorry if this is a bit unfocused, just wanted to get these thoughts down and out in the open for comment. @akaptano @briandesilva @znicolaou.

[akaptano]

Just putting down a flag here that I'm worried of going down the path of adding a lot of links to other codes, because there are potentially A LOT of other symbolic regression codes out there, some of which are not maintained very well, but I would feel pressured to list them all to avoid being seen as playing favorites.

[akaptano]

Also, here is my selfish take:

I think also that the group has spent a lot of time and effort to make PySINDy a really usable and useful symbolic regression code, and that we should encourage others with similar algorithms (like MIOSR, SymINDy, Langevin Regression) to take the time to write it as an extension of the PySINDy code. The authors will get a lot more users to try out their algorithm, and we already have so much of the grunt work done for them -- defining the libraries, optimizers, example scripts, unit tests, etc., that I often think authors are doing themselves a disservice by writing their own code (unless they are using licensed packages, they want to published a JOSS paper, etc.). I keep reading SINDy papers in the literature where I think "wow their results would be way better if they used the weak form or E-SINDy" or "wow they should not have used STLSQ to optimize this" and it would be so easy for them to do so if they used PySINDy. Of course, we need to do some advertising and persuasion to achieve this.

[Jacob-Stevens-Haas]

I completely agree with you Alan. Nothing to add for now, but well-said.