@saninstein ¿

@clstaudt gap es una característica útil para la evaluación de modelos en el comercio de acciones. En la predicción de precios, es un caso muy común cuando el modelo funciona muy bien con los datos justo después del conjunto de entrenamiento y se degrada con el tiempo. Por lo tanto, en algunos casos puede ser útil omitir una pequeña cantidad de datos "buenos" que se produjeron después del conjunto de entrenamiento.

Creo que nuestra posición habitual sobre las características relacionadas con las series de tiempo es que está fuera del alcance de sklearn (al menos por ahora). Y para mí, tendría sentido volver a examinar el asunto una vez que tengamos propiedades de muestra, como la marca de tiempo adjunta a los datos.

Me gustaría tener al menos otra opinión de @ scikit-learn / core-devs sobre esto, pero mi voto es una resolución de "no arreglará" por ahora.

@adrinjalali sklearn ya tiene muchos buenos modelos para series temporales,

¿Cuáles?

@adrinjalali hay TimeSeriesSplit que ya se implementó en sklearn :)

TimeSeriesSplit es un caso específico de WalkForwardCV propuesto (se puede lograr con gap=0, expanding=True args), en realidad TimeSeriesSplit se puede reemplazar fácilmente con WalkForwardCV (solo configure los argumentos predeterminados como mencioné antes).

Soy parte del equipo de ML de negociación de acciones y utilizamos con éxito varias funciones de sklearn y bibliotecas compatibles con sklearn. Faltaba un divisor de CV adecuado y decidimos aportarlo de nuevo a sklearn, pero si este no es el caso, lo usaremos internamente :)

TimeSeriesSplit es un caso específico de WalkForwardCV propuesto (se puede lograr con gap = 0, expandiendo = True args), en realidad TimeSeriesSplit se puede reemplazar fácilmente con WalkForwardCV (solo configure los argumentos predeterminados como mencioné antes).

Justo, pero probablemente trataría de parchear TimeSeriesSplit de una manera compatible con versiones anteriores para agregar la función que necesita. Eso también tiene una mayor probabilidad de ser aceptado por la comunidad.

La predicción de series temporales no es el único caso para WalkForwardCV. Es útil cuando la observación del conjunto de datos se ordena en el tiempo y la validación debe realizarse de la misma manera.

Por ejemplo, una de nuestras tareas es perder el problema de clasificación de filtrado de operaciones cuando intentamos mejorar la estrategia comercial existente con el modelo ml que "dará permiso" para operar.

Correcto, pero probablemente trataría de parchear TimeSeriesSplit de una manera compatible con versiones anteriores para agregar la función que necesita. Eso también tiene una mayor probabilidad de ser aceptado por la comunidad.

Creo que sería la mejor solución.

Soy un científico de datos que trabaja en modelos de predicción de series de tiempo. Asumí que las cosas específicas de la serie de tiempo están fuera del alcance de scikit-learn, así que comencé a implementar mi propio código de validación, ligeramente diferente del método descrito en este hilo.

Más tarde me enteré de la existencia de TimeSeriesSplit y me pregunté si había comenzado a reinventar la rueda. Preferiría contribuir con el código de validación a un proyecto establecido existente.

Dado que existe una clara demanda de este tipo de evaluación de modelos, todavía me pregunto dónde encaja.

Hay muchos patrones que se necesitan para la predicción de series de tiempo. I
pensaría, por ejemplo, que el transformador que crea características de wavelet
será muy útil.

Sin embargo, estos están fuera del alcance de scikit-learn. Seria util
para crear un paquete que implemente todo esto de manera consistente. Eso
probablemente tomaría impulso.

Sería útil crear un paquete que implemente todo esto de manera coherente. Probablemente tomaría impulso.

Si. Inscríbeme.

Estaremos encantados de tener un paquete de este tipo en https://github.com/scikit-learn-contrib/

Cerrando este entonces :)

Creo que está dentro del alcance agregar una mejor validación cruzada de series de tiempo.

ver también # 13666 # 13204 # 6322 # 13761

Con respecto al alcance, estoy de acuerdo con @amueller en que deberíamos estar abiertos a extender esto a casos de uso comunes. Básicamente, generalmente asumimos en los estimadores de scikit-learn (es decir, el paquete sklearn) que el modelo debe ser más o menos invariante con el orden de la muestra y el orden de las características. Esto excluye los estimadores de series de tiempo. Sin embargo, no tenemos esta restricción en los divisores de validación cruzada donde durante mucho tiempo hemos considerado el orden de la muestra como algo a lo que prestar atención; en última instancia, la validación cruzada es donde se encuentran los supuestos centrales en torno al AA.

Pero como también señala @amueller , realmente la conversación debería continuar en las solicitudes de extracción existentes, moviéndolas hacia un estado agradable.

Claro, pero desconfío de los casos en los que la marca de tiempo real de los datos debería importar en la división (lo que debería ser en mi opinión), y no el mero recuento de filas. No creo que vayamos a manejar las marcas de tiempo pronto, ¿verdad?

En los 5 años desde que propuse esto por primera vez en https://github.com/scikit-learn/scikit-learn/issues/3202 , esta pregunta ha surgido al menos 50 veces en conversaciones de enseñanza o aplicación. @saninstein , ¿

También me gustaría contribuir. Escribí en otro número sobre esto y me gustaría ampliar TimeSeriesSplit o colaborar en la creación de otro paquete para eso. Siento que esto es algo que está relacionado con las divisiones en el dominio de CV y ​​debería estar en sklearn.
Para ser honesto, estoy completamente confundido en cuanto a dónde ir y qué hacer ahora que quiero contribuir. Soy consciente de mi tiempo y me gustaría usarlo de la manera correcta para la comunidad.

@mjbommar Creo que, como yo y @jnothman decimos anteriormente, estamos bastante abiertos a seguir adelante y hay algunos RP salientes, en particular # 13761 y # 13204, y los comentarios sobre las dos API serían muy apreciados.

Creo que el # 13204 parece ser el más maduro, así que tal vez ir desde allí tenga más sentido. No estoy seguro de si @kykosic todavía está trabajando en eso, dado el retraso en nuestra respuesta.

Hm, aunque el # 13204 no implementa WalkForward ... ¿Queremos fusionar el # 13204 primero y luego implementar WalkForward más tarde?
¿Debería ser un objeto de CV separado?

@amueller Me había olvidado del # 13204 hasta que apareció esta publicación. Abordaré las críticas durante la próxima semana y veré si todavía encaja.

@kykosic increíble, ¡gracias!

Tengo curiosidad por saber por qué se cerró este problema debido a que se terminó el # 13204. Pensé que el # 13204 era un requisito previo para este.

13204 agregó gap a TimeSeriesSplit que era la característica solicitada por este problema.