Combine methods where possible

[pavelkomarov]

There is a proliferation of variations of methods, which might be more intuitively presented to users as fewer methods with parameters to control each. For example, the total variation module has separate methods for when we care about constant velocity, acceleration, and jerk, which leads to duplicated code. They all call some underlying thing with different parameters. I'd argue we should expose the underlying function with a parameter that controls which derivative we're holding constant.

However, this proposal breaks backwards compatibility in a big way, unless we keep old function signatures around and add warnings that say "they're deprecated, call x instead."

[pavelkomarov]

It's probably also worth collapsing function levels where possible. For example, in _smooth_finite_difference.py, there is a function __median_smooth__, but if I grep -IR . -e "__median_smooth__" I see only two results

./pynumdiff/smooth_finite_difference/_smooth_finite_difference.py:def __median_smooth__(x, window_size):
./pynumdiff/smooth_finite_difference/_smooth_finite_difference.py:        x_hat = __median_smooth__(x_hat, window_size)

This means you're defining this function but only use it in one place. It might be more interpretable when reading the code to do the three lines of this function in situ.

[pavelkomarov]

Possible opportunities under this one:

In _linear_model.py there are front-facing functions lineardiff and polydiff with helpers _lineardiff and _polydiff. The design is that the front-facing function either calls the helper or calls _slide_function, which in turn calls many copies of the helper. It's a rational design, but I suspect there is opportunity to trim some lines/layers and make the code easier to trace by combining front-facing function and helper functionality, perhaps by calling _slide_function in a loop over data slices rather than having it make function calls itself.

In the same file, __integrate_dxdt_hat_matrix__ is only called in one place, so it may not need to be teased out. Depends how readable the caller can be made. Comments to the rescue perhaps.

[pavelkomarov]

I think there is another opportunity here around the optimizer code. Right now each method has its own wrapper for optimization, but I suspect we can call the original functions instead.

[pavelkomarov]

I'm going to consider this one done as of #115. Doing the same for the optimizer code will happen in due course.