@saninstein Pourquoi l'écart ?

@clstaudt gap est une fonctionnalité utile pour l'évaluation des modèles dans le commerce des actions. Dans la prévision des prix, il est très courant que le modèle fonctionne très bien sur les données juste après l'ensemble d'apprentissage et se dégrade avec le temps. Ainsi, dans certains cas, il peut être utile de sauter une petite quantité de "bonnes" données qui se sont produites après l'ensemble d'apprentissage.

Je pense que notre position habituelle sur les fonctionnalités liées aux séries chronologiques est que c'est hors de portée de sklearn (du moins pour l'instant). Et pour moi, il serait logique de réexaminer la question une fois que nous aurons des exemples de propriétés telles que l'horodatage attaché aux données.

J'aimerais avoir au moins un autre avis de @scikit-learn/core-devs à ce sujet, mais mon vote est une résolution "ne corrigera pas" pour l'instant.

@adrinjalali sklearn a déjà les nombreux bons modèles pour les séries temporelles,

Lesquels?

@adrinjalali il y a TimeSeriesSplit qui a déjà été implémenté dans sklearn :)

TimeSeriesSplit est un cas spécifique de WalkForwardCV proposé (peut être obtenu avec des arguments gap=0, expanding=True ), en fait TimeSeriesSplit peut être facilement remplacé par WalkForwardCV (il suffit de définir les arguments par défaut comme je l'ai mentionné précédemment).

Je fais partie de l'équipe ML de négociation d'actions et nous utilisons avec succès diverses fonctionnalités sklearn et bibliothèques compatibles sklearn. Il manquait un séparateur de CV approprié et nous avons décidé de le réintégrer à sklearn, mais si ce n'est pas le cas, nous l'utiliserons en interne :)

TimeSeriesSplit est un cas spécifique de WalkForwardCV proposé (peut être obtenu avec gap=0, expand=True args), en fait TimeSeriesSplit peut être facilement remplacé par WalkForwardCV (il suffit de définir les arguments par défaut comme je l'ai mentionné précédemment).

Correct, mais j'essaierais probablement de patcher TimeSeriesSplit de manière rétrocompatible pour ajouter la fonctionnalité dont vous avez besoin. Cela a aussi plus de chance d'être accepté par la communauté.

La prédiction de séries temporelles n'est pas le seul cas pour WalkForwardCV. C'est utile lorsque l'observation de l'ensemble de données est ordonnée dans le temps et que la validation doit être effectuée de la même manière.

Par exemple, l'une de nos tâches est de perdre le problème de classification de filtrage des transactions lorsque nous essayons d'améliorer la stratégie de négociation existante avec le modèle ml qui "donnera la permission" de négocier.

Correct, mais j'essaierais probablement de corriger TimeSeriesSplit de manière rétrocompatible pour ajouter la fonctionnalité dont vous avez besoin. Cela a aussi plus de chance d'être accepté par la communauté.

Je crois que ce serait la meilleure solution.

Je suis un data scientist travaillant sur des modèles de prévision de séries temporelles. J'ai supposé que les choses spécifiques aux séries temporelles étaient hors de portée de scikit-learn, j'ai donc commencé à implémenter mon propre code de validation, légèrement différent de la méthode décrite dans ce fil.

Plus tard, j'ai appris l'existence de TimeSeriesSplit et je me suis demandé si j'avais commencé à réinventer la roue. Je préférerais contribuer le code de validation à un projet existant et établi.

Puisqu'il y a clairement une demande pour ce genre d'évaluation de modèle, je me demande encore où cela s'inscrit.

Il existe de nombreux modèles qui sont nécessaires pour la prédiction sur les séries chronologiques. je
penserait par exemple qu'un transformateur créant des caractéristiques d'ondelettes
être très utile.

Cependant, ceux-ci sortent du cadre de scikit-learn. ça serait utile
pour créer un package qui implémente tout cela de manière cohérente. Ce
prendrait probablement de l'élan.

Il serait utile de créer un package qui implémente tout cela de manière cohérente. Il prendrait probablement de l'ampleur.

Oui. Enregistre-moi.

Nous serions heureux d'avoir un tel package dans https://github.com/scikit-learn-contrib/

Je ferme celui-ci alors :)

Je pense que l'ajout d'une meilleure validation croisée des séries chronologiques est dans la portée.

voir aussi #13666 #13204 #6322 #13761

En ce qui @amueller que nous devrions être ouverts à l'extension aux cas d'utilisation courants. Fondamentalement, nous supposons généralement dans les estimateurs scikit-learn (c'est-à-dire le package sklearn) que le modèle devrait être plus ou moins invariant à l'ordre d'échantillonnage et à l'ordre des caractéristiques. Cela exclut les estimateurs de séries chronologiques. Cependant, nous n'avons pas cette contrainte dans les séparateurs de validation croisée où nous avons longtemps considéré l'ordre des échantillons comme une chose à laquelle faire attention ; en fin de compte, la validation croisée est l'endroit où se trouvent les hypothèses de base autour du ML.

Mais comme le souligne également

Bien sûr, mais je me méfie des cas où l'horodatage réel des données devrait avoir de l'importance dans la division (ce qu'il devrait faire selon l'OMI), et non le simple nombre de lignes. Je ne pense pas que nous allons gérer les horodatages de sitôt, n'est-ce pas ?

Au cours des 5 années écoulées depuis que j'ai proposé cela pour la première fois sur https://github.com/scikit-learn/scikit-learn/issues/3202 , cette question a été soulevée au moins 50 fois dans des conversations d'enseignement ou d'application. @saninstein , avez-vous pris la décision de faire pression pour l'inclusion ici ou -contrib ? J'aimerais aider s'il y a quelque chose dont vous avez besoin d'aide pour résoudre ce problème (quelque part).

J'aimerais aussi contribuer. J'ai écrit dans un autre numéro à ce sujet et j'aimerais développer TimeSeriesSplit ou collaborer à la création d'un autre package pour cela. Je pense que c'est quelque chose qui est lié aux divisions dans le domaine des CV et devrait être dans sklearn.
Pour être honnête, je ne sais pas trop où aller et quoi faire maintenant que je veux contribuer. Je suis conscient de mon temps et j'aimerais l'utiliser de la bonne manière pour la communauté.

@mjbommar Je pense que comme moi et @jnothman ci-dessus l'avons dit, nous sommes assez ouverts pour aller de l'avant et il y a quelques PR existants, en particulier #13761 et #13204 et des commentaires sur les deux API seraient très appréciés.

Je pense que #13204 semble être le plus mature, alors peut-être que partir de là a le plus de sens ? Je ne sais pas si @kykosic y travaille toujours, étant donné le retard de notre réponse ?

Hm, bien que #13204 n'implémente pas WalkForward... Voulons-nous d'abord fusionner #13204, puis implémenter WalkForward plus tard ?
Cela devrait-il être un objet CV distinct ?

@amueller J'avais oublié le #13204 jusqu'à ce que ce post soit publié. Je vais répondre aux critiques à ce sujet au cours de la semaine prochaine et voir si cela convient toujours.

@kykosic génial, merci !

Curieux de savoir pourquoi ce problème a été fermé en raison de la fin du #13204. Je pensais que #13204 était un pré-requis pour celui-ci.

13204 a ajouté gap à TimeSeriesSplit qui était la fonctionnalité demandée par ce problème.