Auto.arima con datos diarios: ¿cómo capturar la estacionalidad / periodicidad?

Estoy ajustando un modelo ARIMA en una serie de tiempo diaria. Los datos se recopilan diariamente del 02-01-2010 al 30-07-2011 y se refieren a la venta de periódicos. Dado que se puede encontrar un patrón semanal en las ventas (la cantidad promedio diaria de copias vendidas suele ser la misma de lunes a viernes, luego aumenta los sábados y domingos), estoy tratando de capturar esta "estacionalidad". Dados los datos de ventas "datos", creo la serie de tiempo de la siguiente manera:

salests<-ts(data,start=c(2010,1),frequency=365)

y luego uso la función auto.arima (.) para seleccionar el mejor modelo ARIMA a través del criterio AIC. El resultado es siempre un modelo ARIMA no estacional, pero si pruebo algunos modelos SARIMA con la siguiente sintaxis como ejemplo:

sarima1<-arima(salests, order = c(2,1,2), seasonal = list(order = c(1, 0, 1), period = 7))

Puedo obtener mejores resultados. ¿Hay algún problema en la especificación ts command / arima? El patrón semanal es muy fuerte, por lo que no esperaría tantas dificultades para capturarlo. Cualquier ayuda sería muy útil. Gracias Giulia Deppieri.

Actualizar:

Ya he cambiado algunos argumentos. Más precisamente, el procedimiento selecciona ARIMA (4,1,3) como el mejor modelo cuando configuro D=7, pero AIC y los demás índices y pronósticos de buena adaptación tampoco mejoran en absoluto. Supongo que hay algunos errores debido a la confusión entre estacionalidad y periodicidad ...

Auto.arima llamada utilizada y salida obtenida:

modArima<-auto.arima(salests,D=7,max.P = 5, max.Q = 5)



 ARIMA(2,1,2) with drift         : 1e+20
 ARIMA(0,1,0) with drift         : 5265.543
 ARIMA(1,1,0) with drift         : 5182.772
 ARIMA(0,1,1) with drift         : 1e+20
 ARIMA(2,1,0) with drift         : 5137.279
 ARIMA(2,1,1) with drift         : 1e+20
 ARIMA(3,1,1) with drift         : 1e+20
 ARIMA(2,1,0)                    : 5135.382
 ARIMA(1,1,0)                    : 5180.817
 ARIMA(3,1,0)                    : 5117.714
 ARIMA(3,1,1)                    : 1e+20
 ARIMA(4,1,1)                    : 5045.236
 ARIMA(4,1,1) with drift         : 5040.53
 ARIMA(5,1,1) with drift         : 1e+20
 ARIMA(4,1,0) with drift         : 5112.614
 ARIMA(4,1,2) with drift         : 4953.417
 ARIMA(5,1,3) with drift         : 1e+20
 ARIMA(4,1,2)                    : 4960.516
 ARIMA(3,1,2) with drift         : 1e+20
 ARIMA(5,1,2) with drift         : 1e+20
 ARIMA(4,1,3) with drift         : 4868.669
 ARIMA(5,1,4) with drift         : 1e+20
 ARIMA(4,1,3)                    : 4870.92
 ARIMA(3,1,3) with drift         : 1e+20
 ARIMA(4,1,4) with drift         : 4874.095

 Best model: ARIMA(4,1,3) with drift        

Así que supongo que la función arima debería usarse como:

bestOrder <- cbind(modArima$arma[1],modArima$arma[5],modArima$arma[2])
sarima1<-arima(salests, order = c(4,1,3))

sin parámetros de componentes estacionales y especificaciones de período. Los datos y el análisis exploratorio muestran que el mismo patrón semanal puede considerarse de manera aproximada para cada semana, con la única excepción de agosto de 2010 (cuando se registra un aumento constante en las ventas). Desafortunadamente, no tengo experiencia en el modelado de series de tiempo, de hecho, estoy intentando este enfoque para encontrar una solución alternativa a otros modelos paramétricos y no paramétricos que he intentado ajustar para estos datos problemáticos. También tengo muchas variables numéricas dependientes, pero han demostrado poco poder para explicar la variable de respuesta: sin duda, la parte más difícil de modelar es el componente de tiempo. Además, la construcción de variables ficticias para representar meses y días de la semana no resultó ser una solución sólida.

Si hay estacionalidad semanal, establezca el período estacional en 7.

salests <- ts(data,start=2010,frequency=7) 
modArima <- auto.arima(salests)

Tenga en cuenta que la selección de la diferenciación estacional no fue muy buena auto.arima()hasta hace muy poco. Si está utilizando v2.xx del forecastpaquete, configúrelo D=1en la llamada a auto.arima()para forzar la diferenciación estacional. Si está utilizando v3.xx del forecastpaquete, la selección automática de Dfunciona mucho mejor (utilizando una prueba OCSB en lugar de una prueba CH).

No intente comparar el AIC para modelos con diferentes niveles de diferenciación. No son directamente comparables. Solo puede comparar de manera confiable el AIC con modelos que tienen los mismos órdenes de diferenciación.

No necesita volver a ajustar el modelo después de llamar auto.arima(). Devolverá un objeto Arima, como si hubiera llamado arima()con el orden de modelo seleccionado.

El problema con el ajuste de ARIMA estacional a los datos diarios es que el "componente estacional" solo puede operar los fines de semana o tal vez solo los días laborables, por lo tanto, en general, hay un "componente estacional" no significativo. Ahora lo que tiene que hacer es aumentar su conjunto de datos con 6 dummies que representan los días de la semana y quizás indicadores mensuales para representar los efectos anuales. Ahora considere incorporar eventos tales como vacaciones e incluya cualquier efecto principal, contemporáneo o de retraso en torno a estas variables conocidas. No, puede haber valores inusuales (pulsos) o cambios de nivel o tendencias de hora local en los datos. Además, los efectos del día de la semana pueden haber cambiado con el tiempo, por ejemplo, no hubo efecto de sábado durante las primeras 20 semanas, sino un efecto de sábado durante las últimas 50 semanas.

Para determinar el orden de estacionalidad en mis ts (datos diarios a lo largo de 3 años) he usado este código en Matlab:

s = 0; min = 1e + 07; n = longitud (x); para i = 1: 400 diff = x (i + 1: n) -x (1: ni); s (i) = suma (abs (diff)); si (s (i)

Me da 365 que es lógico.