Different KDE implementations

[tpvasconcelos]

We have experienced some issues in the past with statsmodels' KDE implementation (see in-line comments in ridgeplot._kde.estimate_density_trace().

• Most obvious option: scipy.stats.gaussian_kde
• Some dedicated libraries:
  • https://github.com/LBL-EESA/fastkde
  • https://github.com/tommyod/KDEpy
• Python 3.13 will ship a kde() utility as part of the built-in statistics module:
  • https://docs.python.org/3.13/library/statistics.html#statistics.kde
  • https://docs.python.org/3.13/library/statistics.html#sampling-from-kernel-density-estimation
  • https://github.com/python/cpython/pull/115863
  • https://github.com/python/cpython/issues/115532

Things to keep in mind:

• Backwards compatibility with the existing ridgeplot() arguments that are passed to statsmodels' KDEUnivariate
• Performance. e.g., statsmodels provides a faster FFT implementation when using the gaussian kernel.
• ...more?

[fkiraly]

Design-wise, would it not be cleanest to:

• separate plotting from density estimation a-priori
• leave some configurability which method to use?

I wanted to write some abstract density estimation intefaces anyway, for skpro (though ofc no need to use them - just saying that I have done some thinking around that topic).

[tpvasconcelos]

The main contender here would be scipy's scipy.stats.gaussian_kde which is used by pandas in pandas.Series.plot.kde. However, this version lacks some features provided by statsmodels which is an issue for backwards compatibility.

In principle I agree with @fkiraly that it would be better to separate density estimation (and in the future: histogram binning) from the plot factory. However, this project tried to follow the design patterns in the Plotly Express API from the beginning which resulted in exposing the KDE logic to the figure factory function.

I'm closing this issue for now as I don't see a strong need to make large changes to this logic atm...