Description of the problem/new feature
There are a few places where methods use different parameter names that mean the same thing. For consistency's sake, it'd be nice to pick one keyword and deprecate all other usages.
loess uses symmetric_weights, where I think all other places like mixture_model and beads just use symmetric
penalized_poly could also get symmetric added such that it's cost_function term can be a simple 3-option enum (goldindec could likewise be updated), although I'm not entirely sold on the idea
rubberband uses segments while golotvin and peak_filling use sections
snip and swima use max_half_window; the meaning's technically different than just half_window, but I think it's close enough to justify changing to half_window since the later term is used everywhere else for smoothers
custom_bc should use lam_smooth instead of lam
And while I'm at it, since v1.3 is shaping up to be the "deprecation version", I should rename loess and penalized_poly:
loess should be renamed to lowess; way back when I implemented it, I thought "loess" just meant "lowess" for higher polynomial orders, but it's an entirely separate algorithm; naming it loess dilutes Cleveland's algorithm naming scheme, which wasn't my intention
- should also be moved to smooth since labeling it as a polynomial is a bit of a misnomer
penalized_poly should be renamed to robust_poly; again, a misunderstanding on my part; a penalized polynomial would make one think of Tikhonov regularization rather than what penalized_poly does, which is more akin to robust regression/M-estimation.
Description of the problem/new feature
There are a few places where methods use different parameter names that mean the same thing. For consistency's sake, it'd be nice to pick one keyword and deprecate all other usages.
loessusessymmetric_weights, where I think all other places like mixture_model and beads just usesymmetricpenalized_polycould also getsymmetricadded such that it'scost_functionterm can be a simple 3-option enum (goldindec could likewise be updated), although I'm not entirely sold on the idearubberbandusessegmentswhilegolotvinandpeak_fillingusesectionssnipandswimausemax_half_window; the meaning's technically different than justhalf_window, but I think it's close enough to justify changing tohalf_windowsince the later term is used everywhere else for smootherscustom_bcshould uselam_smoothinstead oflamAnd while I'm at it, since v1.3 is shaping up to be the "deprecation version", I should rename
loessandpenalized_poly:loessshould be renamed tolowess; way back when I implemented it, I thought "loess" just meant "lowess" for higher polynomial orders, but it's an entirely separate algorithm; naming itloessdilutes Cleveland's algorithm naming scheme, which wasn't my intentionpenalized_polyshould be renamed torobust_poly; again, a misunderstanding on my part; a penalized polynomial would make one think of Tikhonov regularization rather than whatpenalized_polydoes, which is more akin to robust regression/M-estimation.