Datetime encoder

[LeoGrin]

Creates a new encoder which transform datetime columns into several numerical features (year, month, day...). Solves the second part of #233.

[LilianBoulard]

Here's bunch of small adjustments, but overall this is very good ! Thank you :)

[LeoGrin]

Thank you for the review @LilianBoulard !

[GaelVaroquaux]

Nice!

I left a few comments, but none of them are major.

The new object should be added to the list of encoders on the first page (doc/index.rst).

We also need an example demonstrating the new object.

[GaelVaroquaux]

My gut feeling is that the "other" feature would make the learning easier if it were the full time to epoch. Else, the model may need to learning the weird algebra: 24H, 30 days a months but not quite, 365 days in a year and sometimes not.
Probably, having both features would be useful....

[LeoGrin]

Hmm interesting. I get you point, but here's why I chose to do it this way:

• I fear that full_time_to_epoch would be very collinear with the highest-level feature, hurting interpretability. For a worst case scenario, we can imagine a dataset of different hours during the same day for different years.
• It’s true that with my choice, the learner has to learn the weird algebra. But with your proposition, the learner would still need to learn this weird algebra if it wants to use my other feature (which may be more important for prediction since it’s information which isn’t contained in the other variables), because other = full_time_to_epoch - (year - 1970) * 365 * 24 * 3600 + …

Maybe using both could indeed make the learning easier, but wouldn't you worry about collinearity?
All in all I'm not sure.

[GaelVaroquaux]

I do machine learning. I don't worry about collinearity :).

It does not hurt for prediction. I can hurt for interpretability.

[GaelVaroquaux]

My reason for favoring the full_time_to_epoch is that I think that, in general, it is more likely to be useful than the other end, and we are more likely to have to reconstruct it.

[GaelVaroquaux]

Do you think a new dependency is worth it?

No, I don't think that a new dependency is worth it. I'm wondering if we should simply drop this feature (less features = less code = less problems :D )

[LeoGrin]

Additions:

• Replaced the "other" feature by the "full" features, which contains the full time to epoch (see above discussion with @GaelVaroquaux)
• Made the DatetimeEncoder the default for datetime columns in the SuperVectorizer
• Added a simple example
• Small fixes

[LeoGrin]

Apparently using fetch_traffic_violations() in the example takes too much memory for circleCI

[LeoGrin]

I've changed the example to use another dataset, I think the PR is ready for review @LilianBoulard @GaelVaroquaux @jovan-stojanovic

[GaelVaroquaux]

A few changes requested. Most are minor. I hope that the prediction example won't ask for too much work.

[GaelVaroquaux]

Would it be possible to do a small prediction model at the end, add a section, to showcase this in a prediction pipeline?

For didactic purposes it would be important to have not only the cross-validation (using https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html ) but also the plot of the extrapolated time series (compared to the real one)

[LeoGrin]

Thank you for the comments! I've added a new section to the example

[GaelVaroquaux]

Oups, I just saw that there is a "examples/.DS_Store" that needs to be removed. You can add it in the gitignore if it's helpful.

[GaelVaroquaux]

Still cosmetic comments on the example :)

[GaelVaroquaux]

LGTM. Thanks a lot!

[GaelVaroquaux]

Hum, I merged this, but I hadn't seen that the lines are too long (I'll fix it, I wanted to do cosmetics on the example anyhow).

It does have a practical consequence: it forces horizontal scrolling in the example, which is bad for readability.

[GaelVaroquaux]

This actually made me wonder: in which case should I use a class attribute vs a module-level constant?

Use a class attribute if you might want to override it in a subclass.