Auto.arima avec des données quotidiennes: comment capturer la saisonnalité / périodicité?

Je monte un modèle ARIMA sur une série temporelle quotidienne. Les données sont collectées quotidiennement du 02-01-2010 au 30-07-2011 et concernent les ventes de journaux. Puisqu'une tendance hebdomadaire des ventes peut être trouvée (la quantité moyenne quotidienne d'exemplaires vendus est généralement la même du lundi au vendredi, puis augmente le samedi et le dimanche), j'essaie de saisir cette "saisonnalité". Compte tenu des données de vente "données", je crée la série chronologique comme suit:

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

puis j'utilise la fonction auto.arima (.) pour sélectionner le meilleur modèle ARIMA via le critère AIC. Le résultat est toujours un modèle ARIMA non saisonnier, mais si j'essaie un modèle SARIMA avec la syntaxe suivante comme exemple:

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

Je peux obtenir de meilleurs résultats. Y a-t-il quelque chose qui cloche dans la spécification ts command / arima? Le schéma hebdomadaire est très fort, donc je ne m'attendrais pas à autant de difficultés à le capturer. Toute aide serait très utile. Merci, Giulia Deppieri

Mise à jour:

J'ai déjà changé certains arguments. Plus précisément, la procédure sélectionne ARIMA (4,1,3) comme le meilleur modèle lorsque je mets D=7, mais AIC et les autres bons indices d'ajustement et prévisions) ne s'améliorent pas du tout. Je suppose qu'il y a des erreurs dues à la confusion entre la saisonnalité et la périodicité ..?!

Appel Auto.arima utilisé et sortie obtenue:

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        

Je suppose donc que la fonction arima doit être utilisée comme:

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

sans paramètres de composants saisonniers et spécifications de période. Les données et l'analyse exploratoire montrent que le même schéma hebdomadaire peut être considéré approximativement pour chaque semaine, à la seule exception d'août 2010 (où une augmentation constante des ventes est enregistrée). Malheureusement, je n'ai aucune expertise en modélisation de série temporelle, en fait j'essaie cette approche afin de trouver une solution alternative à d'autres modèles paramétriques et non paramétriques que j'ai essayé d'adapter à ces données problématiques. J'ai également de nombreuses variables numériques dépendantes mais elles ont montré une faible puissance pour expliquer la variable de réponse: sans aucun doute, la partie la plus difficile à modéliser est la composante temporelle. De plus, la construction de variables muettes pour représenter les mois et les jours de la semaine s'est avérée ne pas être une solution robuste.

En cas de saisonnalité hebdomadaire, définissez la période saisonnière sur 7.

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

Notez que la sélection de la différenciation saisonnière n'était pas très bonne auto.arima()jusqu'à très récemment. Si vous utilisez la v2.xx du forecastpackage, définissez D=1l'appel à auto.arima()pour forcer la différenciation saisonnière. Si vous utilisez la v3.xx du forecastpackage, la sélection automatique de Dfonctionne bien mieux (en utilisant un test OCSB au lieu d'un test CH).

N'essayez pas de comparer l'AIC pour des modèles avec différents niveaux de différenciation. Ils ne sont pas directement comparables. Vous ne pouvez comparer de manière fiable l'AIC qu'avec des modèles ayant les mêmes ordres de différenciation.

Vous n'avez pas besoin de réajuster le modèle après avoir appelé auto.arima(). Il renverra un objet Arima, comme si vous aviez appelé arima()avec l'ordre de modèle sélectionné.

Le problème lié à l'ajustement de l'ARIMA saisonnier aux données quotidiennes est que la "composante saisonnière" ne peut fonctionner que le week-end ou peut-être uniquement les jours de semaine, donc globalement il y a une "composante saisonnière" non significative. Maintenant, ce que vous devez faire est d'augmenter votre ensemble de données avec 6 variables indicatrices représentant les jours de la semaine et peut-être des indicateurs mensuels pour représenter les effets annuels. Envisagez maintenant d'incorporer des événements tels que les vacances et d'inclure tout effet de plomb, de contamination ou de décalage autour de ces variables connues. Non, il peut y avoir des valeurs inhabituelles (impulsions) ou des changements de niveau ou des tendances temporelles locales dans les données. De plus, les effets du jour de la semaine peuvent avoir changé au fil du temps, par exemple il n'y a pas eu d'effet samedi pour les 20 premières semaines mais un effet samedi pour les 50 dernières semaines.

Pour déterminer l'ordre de saisonnalité de mes ts (données quotidiennes sur 3 ans), j'ai utilisé ce code dans Matlab:

s = 0; min = 1e + 07; n = longueur (x); pour i = 1: 400 diff = x (i + 1: n) -x (1: ni); s (i) = somme (abs (diff)); si (s (i)

Cela me donne 365, ce qui est logique.