Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Improve smoother functions and kernels #999

Open
randomboolean opened this issue Jul 30, 2021 · 0 comments
Open

[Discussion] Improve smoother functions and kernels #999

randomboolean opened this issue Jul 30, 2021 · 0 comments

Comments

@randomboolean
Copy link
Contributor

randomboolean commented Jul 30, 2021

LOWESS and RLOWESS as smoother functions have the following limitations:

  • there is no sliding window (at each point, the K nearest neighbors are fetched)
  • only one kernel is available (tricube)
  • the bandwidth of the kernel is variable and is equal to the distance between the current tick and the furthest neighbor

On the other hand, the family of smoother mappers of the type mapper.kernel.* have the following limitations:

  • the computation of the smoother weights is discretized
  • the bandwidth of the kernel is fixed and is computed from the parameters
  • the semantic of parameters bandwidth and step can be misleading
  • only regression using weighted average is available

These limitations do not overlap.

  1. To answer all these limitations, we may deprecate mapper.kernel.* and implement another family, for example coined mapper.smoother.*, or mapper.regression.* such that:
  • the computation of weights is exact (instead of precomputed on a discrete set of values)
  • they took a parameter bandwidth expressed in time unit, for which 0 means 'maximize the bandwidth automatically at each point' (like in the case of LOWESS and RLOWESS)
  • they took a parameter degree for the degree of the polynomial fit, (0 means 'weighted averages' like current behavior)
  1. LOWESS and RLOWESS have a feature that can be interesting for MAP, namely, creating the window at each point using the K nearest neighbors. This could be also implemented in MAP, or as a variant, for example MAP.NEAR, by reusing the code of MAP except for computing the window (instead of pre and post parameters, MAP.NEAR could have k and max.neighbor.distance parameters).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant