FEAT add the Frequency Encoder

[coconutattitude]

Addresses #706 issue.
Here's a first iteration of the class and it's a proof of concept made during EuroSciPy 2023. Documentation and tests are needed. I'll add quantile strategies in the future. What do you think about this proof of concept?

[Vincent-Maladiere]

Thanks for this feature, @coconutattitude
Here is a quick roadmap to improve this PR before engaging in more formal reviews and discussions.

1. Use pre-commit to linter and standardize your code (it is usually run during git commit).
   To do so:

   pip install -e '.[dev]'

   to install the dependencies used for development, then:

   pre-commit init

   to initialize pre-commit.

2. Add a get_feature_name_out() method.
   This is useful for inspecting the data used to fit transformers.
   You can take inspiration from the GapEncoder method or DatetimeEncoder method

3. Check for input types, i.e. what happens when X is a numpy array? What happens when it's a pandas dataframe?
   Most encoders/estimators across skrub use the check_input() utils function.
   

   skrub/skrub/_datetime_encoder.py

   Lines 192 to 196 in 9d2e64f

   	if isinstance(X, pd.DataFrame):
   	self.col_names_ = X.columns.to_list()
   	else:
   	self.col_names_ = None
   	X = check_input(X)

4. Add basic tests in a dedicated _test_frequency_encoder.py file test. This will help discover edge cases and situations in which the estimator would fail.

5. Convert your example notebook into a Python file using jupytext

   pip install jupytext
   

   then:

   jupytext --set-formats ipynb,py:percent example/08_frequence_encoder.ipynb
   jupytext --sync example/08_frequence_encoder.ipynb
   

   We prefer Python files over notebooks because we can review them in PR more easily, and they are more compact.

6. Enrich your example by adding a regression/classification or even clustering task. Reproducing a similar use case to the one you mentioned IRL with IP addresses could bring value.

[Vincent-Maladiere]

Hi @coconutattitude, are you planning to continue this PR?

[jeromedockes]

shall we try to revive this? :) it would be a nice addition

[Vincent-Maladiere]

@rcap107 are you interested in continuing this PR once StringEncoder is merged?

[rcap107]

I can work on it, yes

[rcap107]

This feature was implemented in #1235

[Vincent-Maladiere]

This feature was implemented in #1235

I don't think it was because this PR aims to encode categories using their frequencies; hence, I don't see how the periodic encoder solves this. WDYT?

[GaelVaroquaux]

I don't think it was because this PR aims to encode categories using their frequencies; hence, I don't see how the periodic encoder solves this. WDYT?

I agree. I might have misunderstood this PR. Given that such encoder is quite popular, I am +1 with the proposed feature.

[rcap107]

This feature was implemented in #1235

I don't think it was because this PR aims to encode categories using their frequencies; hence, I don't see how the periodic encoder solves this. WDYT?

My bad, I mixed up this PR and the old discussion on the periodic encoder. This is absolutely unrelated from #1235