Should Methods be Regrouped?

[pavelkomarov]

The modules currently make some sense, but linear_model especially is kind of a catch-all. I've been pondering how many distinct methods there really are here, and I think the number is 7:

1. Convolve with filter -> FD
2. Polynomial-based: Splines, Sliding Polyfit, and SavGol
3. Spectral with tricks
4. TVR
5. Kalman (RTS)
6. Iterated FD
7. Lineardiff

Four of these have good homes: Iterated FD, Smoothed FD, Kalman, and TVR.

Splines, Sliding Poly, and SavGol are related. SavGol is actually a special case of Sliding Poly. Splinediff currently lives in smoothed FD, although I updated it to not use FD in #137, and Splines can naturally handle irregularly-spaced data (#80), unlike the convolutional-filter-based methods in the rest of that module, so they seem to really not belong there. The other two currently live in linear_model, but I'd emphasize their polynomial-ness if I were regrouping from scratch.

(Fourier) spectral with tricks is a funny case. It's like you're really not supposed to do this on arbitrary signals, but it's so good for culling high frequency noise that we can contort and abuse the method and actually do okay.

That leaves Lineardiff, which is the longest in code, longest by runtime, most fragile, not particularly accurate, left out of the method-suggestion function's list, and least touched by Pavel's hands. It's its own approach, somewhat distinct from everything else, valuable to keep around and possibly tinker with, but probably the most challenging to work on.

What to do with the singletons can be a question, but honestly I see all the RTS, Iterated FD, and TVR methods as multiple expressions of a singleton too. The public-facing methods of each of those modules call down to their single private backing functions, ultimately, so I favor more groups, even if each only has a single public interface. Then again, maybe that extra layer, splintered too finely, adds friction for users. Should we instead make all methods importable at the top level and emphasize modules only as a conceptual and code-organizational structure?

If we are to mess with this, it will naively break imports and therefore backwards compatibility, so I'd first make each method importable in two ways, with the old places triggering deprecation warnings. Then the new release starts steering users appropriately, and in a couple years I go rectify, pull out the redundancy both for this and for params/options, and clean up all the warnings.

[pavelkomarov]

If this is undertaken, the example notebooks should also be mildly reorganized. Or alternatively methods could be regrouped in there without needing to do anything to the underlying code.

Follow up: I have reorganized the 2a and 2b notebooks. They're significantly shorter if we replace multiple methods with optimizations over the common backing method, and they take less time to run. See #143. I considered doing likewise to the basic usage notebook and decided to leave it as is, since basic usage may involve calling whichever particular method signature is your favorite.

[pavelkomarov]

As of #145, I'm satisfied with this one. The most odd pairings are no longer together, and everything is importable both from the module and at the package top level, as well as from the old locations for backwards compatibility. Could go one step further and separate lineardiff from spectraldiff, but that one doesn't bug me as much, and Fourier transforms are linear, so ¯\_(ツ)_/¯.

[pavelkomarov]

With the introduction of rbfdiff, I've been noodling on the idea that it has a lot in common with spectraldiff, because both fit basis functions by solving the problem:

$$\begin{bmatrix} \xi_{0,0} & \xi_{1,0} & \cdots & \xi_{N-1,0}\\ \xi_{0,1} & \xi_{1,1} & \cdots &\xi_{N-1,1} \\ \vdots & \vdots & \ddots & \vdots\\ \xi_{0,N-1} & \xi_{1,N-1} & \cdots & \xi_{N-1,N-1} \end{bmatrix} \begin{bmatrix} c_0\\ c_1 \\ \vdots \\ c_{N-1} \end{bmatrix} = \begin{bmatrix} y_0 \\ y_1 \\ \vdots \\ y_{N-1} \end{bmatrix}$$

where $\xi_{k,n}$ is the value of the $k^\text{th}$ basis function at the $n^\text{th}$ sample point.

They're actually both global methods, mathematically, although I make the radial basis function method local for computational efficiency, because the basis functions have such small values past some radius that it's not worth computing. I put rbfdiff in the linear_model module with spectraldiff for that reason, but they're really conceptually their own thing. I want them to have a home of their own that emphasizes the basis-function theme.

splinediff is also really basis-function-based too, because UnivariateSpline uses B-splines, so it could go in either module, but I feel like it conceptually belongs where it is. Maybe I'll reorder some things in the paper and use splines as a bridge.