Prévision de séries chronologiques horaires avec périodicité quotidienne, hebdomadaire et annuelle

12

Édition majeure: Je voudrais dire un grand merci à Dave et Nick jusqu'à présent pour leurs réponses. La bonne nouvelle est que j'ai réussi à faire fonctionner la boucle (principe emprunté à la publication du professeur Hydnman sur la prévision par lots). Pour consolider les requêtes en attente:

a) Comment puis-je augmenter le nombre maximal d'itérations pour auto.arima - il semble qu'avec un grand nombre de variables exogènes, auto.arima atteint le nombre maximal d'itérations avant de converger vers un modèle final. Veuillez me corriger si je ne comprends pas bien.

b) Une réponse, de Nick, souligne que mes prédictions pour les intervalles horaires ne sont dérivées que de ces intervalles horaires et ne sont pas influencées par des événements plus tôt dans la journée. Mon instinct, en traitant ces données, me dit que cela ne devrait pas souvent causer un problème important, mais je suis ouvert à des suggestions sur la façon de traiter cela.

c) Dave a souligné que j'avais besoin d'une approche beaucoup plus sophistiquée pour identifier les temps de latence / retard entourant mes variables prédictives. Quelqu'un a-t-il une expérience avec une approche programmatique de cela dans R? Bien sûr, je m'attends à ce qu'il y ait des limites, mais je voudrais pousser ce projet aussi loin que je le peux, et je ne doute pas que cela doit également être utile à d'autres ici.

d) Nouvelle requête mais entièrement liée à la tâche à accomplir - auto.arima prend-il en compte les régresseurs lors de la sélection des commandes?

J'essaie de prévoir les visites dans un magasin. J'ai besoin de la capacité de rendre compte des vacances mobiles, des années bissextiles et des événements sporadiques (essentiellement des valeurs aberrantes); sur cette base, je suppose que ARIMAX est mon meilleur pari, en utilisant des variables exogènes pour essayer de modéliser la saisonnalité multiple ainsi que les facteurs susmentionnés.

Les données sont enregistrées 24 heures à intervalles horaires. Cela s'avère problématique en raison de la quantité de zéros dans mes données, en particulier à des moments de la journée qui voient de très faibles volumes de visites, parfois pas du tout lorsque le magasin vient d'ouvrir. De plus, les heures d'ouverture sont relativement irrégulières.

De plus, le temps de calcul est énorme lorsque l'on prévoit une série chronologique complète avec 3 ans + de données historiques. Je pensais que cela le rendrait plus rapide en calculant chaque heure de la journée sous forme de séries chronologiques distinctes, et lorsque le tester à des heures plus occupées de la journée semble donner une plus grande précision, mais se révèle à nouveau devenir un problème avec les heures tôt / tard qui ne fonctionnent pas '' t recevoir régulièrement des visites. Je pense que le processus gagnerait à utiliser auto.arima mais il ne semble pas pouvoir converger sur un modèle avant d'atteindre le nombre maximal d'itérations (d'où l'utilisation d'un ajustement manuel et de la clause maxit).

J'ai essayé de gérer les données «manquantes» en créant une variable exogène pour quand les visites = 0. Encore une fois, cela fonctionne très bien pour les moments plus occupés de la journée où la seule fois où il n'y a pas de visites est lorsque le magasin est fermé pour la journée; dans ces cas, la variable exogène semble gérer cette situation avec succès pour les prévisions à venir et sans tenir compte de l'effet de la clôture de la journée précédente. Cependant, je ne sais pas comment utiliser ce principe en ce qui concerne la prévision des heures plus calmes où le magasin est ouvert mais ne reçoit pas toujours de visites.

Avec l'aide du message du professeur Hyndman sur les prévisions par lots dans R, j'essaie de mettre en place une boucle pour prévoir les 24 séries, mais il ne semble pas vouloir prévoir à 13 heures et je ne peux pas comprendre pourquoi. J'obtiens "Erreur dans optim (init [mask], armafn, method = optim.method, hessian = TRUE,: valeur de différence finie non finie [1]" mais comme toutes les séries sont de longueur égale et j'utilise essentiellement la même matrice, je ne comprends pas pourquoi cela se produit. Cela signifie que la matrice n'est pas de plein rang, non? Comment puis-je éviter cela dans cette approche?

https://www.dropbox.com/s/26ov3xp4ayig4ws/Data.zip

date()

#Read input files
INPUT <- read.csv("Input.csv")
XREGFDATA <- read.csv("xreg.csv")

#Subset time series data from the input file
TS <- ts(INPUT[,2:25], f=7)


fcast <- matrix(0, nrow=nrow(XREGFDATA),ncol=ncol(TS))

#Create matrix of exogenous variables for forecasting.
xregf <- (cbind(Weekday=model.matrix(~as.factor(XREGFDATA$WEEKDAY)),
                    Month=model.matrix(~as.factor(XREGFDATA$MONTH)),
                Week=model.matrix(~as.factor(XREGFDATA$WEEK)),
                    Nodata=XREGFDATA$NoData,
                NewYearsDay=XREGFDATA$NewYearsDay,
                    GoodFriday=XREGFDATA$GoodFriday,
                EasterWeekend=XREGFDATA$EasterWeekend,
                    EasterMonday=XREGFDATA$EasterMonday,
                MayDay=XREGFDATA$MayDay,
                    SpringBH=XREGFDATA$SpringBH,
                SummerBH=XREGFDATA$SummerBH,
                    Christmas=XREGFDATA$Christmas,
                BoxingDay=XREGFDATA$BoxingDay))
#Remove intercepts
xregf <- xregf[,c(-1,-8,-20)]

NoFcast <- 0

for(i in 1:24) {

  if(max(INPUT[,i+1])>0) {

  #The exogenous variables used to fit are the same for all series except for the
  #'Nodata' variable. This is to handle missing data for each series
   xreg <- (cbind(Weekday=model.matrix(~as.factor(INPUT$WEEKDAY)),
                     Month=model.matrix(~as.factor(INPUT$MONTH)),
                 Week=model.matrix(~as.factor(INPUT$WEEK)),
                     Nodata=ifelse(INPUT[,i+1] < 1,1,0),
                     NewYearsDay=INPUT$NewYearsDay,
                 GoodFriday=INPUT$GoodFriday,
                     EasterWeekend=INPUT$EasterWeekend,
                 EasterMonday=INPUT$EasterMonday,
                     MayDay=INPUT$MayDay,
                 SpringBH=INPUT$SpringBH,
                     SummerBH=INPUT$SummerBH,
                 Christmas=INPUT$Christmas,
                     BoxingDay=INPUT$BoxingDay))
  xreg <- xreg[,c(-1,-8,-20)]

  ARIMAXfit <- Arima(TS[,i], 
                     order=c(0,1,8), seasonal=c(0,1,0),
                     include.drift=TRUE,
                     xreg=xreg,
                     lambda=BoxCox.lambda(TS[,i])
                     ,optim.control = list(maxit=1500), method="ML")  


  fcast[,i] <- forecast(ARIMAXfit, xreg=xregf)$mean

 } else{
  NoFcast <- NoFcast +1
 }
}

#Save the forecasts to .csv
write(t(fcast),file="fcasts.csv",sep=",",ncol=ncol(fcast))


date()

J'apprécierais pleinement les critiques constructives de la façon dont je procède et toute aide pour faire fonctionner ce script. Je suis conscient qu'il existe d'autres logiciels mais je suis strictement limité à l'utilisation de R et / ou SPSS ici ...

De plus, je suis très nouveau sur ces forums - j'ai essayé de fournir une explication aussi complète que possible, de démontrer les recherches antérieures que j'ai faites et de fournir également un exemple reproductible; J'espère que cela suffit, mais faites-moi savoir s'il y a autre chose que je peux fournir pour améliorer mon message.

EDIT: Nick a suggéré que j'utilise d'abord les totaux quotidiens. Je dois ajouter que j'ai testé cela et que les variables exogènes produisent des prévisions qui saisissent la saisonnalité quotidienne, hebdomadaire et annuelle. C'était l'une des autres raisons pour lesquelles je pensais prévoir chaque heure comme une série distincte, mais comme Nick l'a également mentionné, mes prévisions pour 16 heures un jour donné ne seront pas influencées par les heures précédentes de la journée.

EDIT: 09/08/13, le problème avec la boucle était simplement lié aux commandes d'origine que j'avais utilisées pour les tests. J'aurais dû repérer cela plus tôt et mettre plus d'urgence sur l'auto.arima pour travailler avec ces données - voir les points a) et d) ci-dessus.

krcooke
la source
En outre, j'ai essayé d'utiliser fourier pour gérer la saisonnalité, mais j'ai renvoyé la même erreur "Erreur dans optim (init [mask], armafn, method = optim.method, hessian = TRUE,: valeur de différence finie non finie [1]") même lorsqu'il est utilisé comme matrice à part entière sans aucune autre variable exogène. Est-ce que quelqu'un pourrait m'aider à expliquer pourquoi cela serait le cas?
krcooke
pourriez-vous retélécharger les données?
MyHeadHurts

Réponses:

4

Malheureusement, votre mission est vouée à l'échec car vous êtes limité à R et SPSS. Vous devez identifier la structure des relations entre les pistes et les décalages pour chacun des événements / vacances / variables exogènes qui peuvent entrer en jeu. Vous devez détecter d'éventuelles tendances temporelles que SPSS ne peut pas faire. Vous devez incorporer les tendances / prévisions quotidiennes dans chacune des prévisions horaires afin de fournir une prévision consolidée et réconciliée. Vous devez vous préoccuper de changer les paramètres et de changer la variance. J'espère que cela t'aides. Nous modélisons ce type de données depuis des années de manière automatique, sous réserve bien sûr de contrôles facultatifs spécifiés par l'utilisateur.

EDIT: Comme OP l'a demandé, je présente ici une analyse typique. J'en ai pris une si les heures étaient plus chargées et j'ai développé un modèle quotidien. Dans une analyse complète, les 24 heures seraient développées ainsi qu'un modèle quotidien afin de concilier les prévisions. Voici une liste partielle du modèle entrez la description de l'image ici. En plus des régresseurs significatifs (notez que la structure réelle du plomb et du décalage a été omise), il y avait des indicateurs reflétant la saisonnalité, les changements de niveau, les effets quotidiens, les changements dans les effets quotidiens et les valeurs inhabituelles non cohérentes avec l'histoire. Les statistiques du modèle sont entrez la description de l'image ici. Un graphique des prévisions pour les 360 prochains jours est présenté ici entrez la description de l'image ici. Le graphique réel / ajustement / prévision résume parfaitement les résultatsentrez la description de l'image iciFace à un problème extrêmement complexe (comme celui-ci!), Il faut faire preuve de beaucoup de courage, d'expérience et d'aides à la productivité informatique. Informez simplement votre direction que le problème est résolu mais pas nécessairement en utilisant des outils primitifs. J'espère que cela vous encourage à poursuivre vos efforts car vos commentaires précédents ont été très professionnels, orientés vers l'enrichissement personnel et l'apprentissage. J'ajouterais qu'il faut connaître la valeur attendue de cette analyse et l'utiliser comme ligne directrice lors de l'examen de logiciels supplémentaires. Peut-être avez-vous besoin d'une voix plus forte pour aider à orienter vos «directeurs» vers une solution réalisable à cette tâche difficile.

Après avoir examiné les totaux quotidiens et chacun des modèles de 24 heures, je penserais certainement que le nombre de visites est en grave baisse! Ce type d'analyse par un acheteur potentiel suggérerait un non-achat tandis qu'un vendeur serait sage de redoubler d'efforts pour vendre l'entreprise sur la base de cette projection très négative.

IrishStat
la source
Salut Dave, merci beaucoup d'avoir pris le temps de lire ma question et d'y répondre. Je comprends que votre logiciel va au-delà de toute alternative mais n'est malheureusement pas une option pour moi pour le moment. Connaissant les capacités de R, pouvez-vous me donner des conseils pour améliorer ce que j'ai déjà fait?
Cordialement
@krcooke Vous pouvez examiner la corrélation croisée entre les visites et les pistes / retards alternatifs autour de chacun de vos régresseurs afin d'identifier la réponse appropriée.Je suis totalement d'accord avec Nick que certains régresseurs pourraient être utiles pour certaines heures mais pas pour d'autres. Vous pouvez modéliser chaque heure séparément.La détection des 4 types de valeurs aberrantes (impulsion, changement de niveau, impulsion saisonnière et tendances temporelles) n'est pas disponible dans SAS lorsque vous avez des causes et n'est probablement pas disponible dans SPSS.J'ai téléchargé vos données et utiliserai AUTOBOX Nous recherchons toujours des "données solides" comme la vôtre pour renforcer nos analyses.
IrishStat
Salut Dave, je vais voir ce que je peux faire autour de l'analyse des régresseurs. Je sentais que les régresseurs que j'utilisais étaient très «standard» et susceptibles d'avoir un impact sur tous ces magasins. J'ai utilisé le week-end du jour férié jubilé comme exemple dans le commentaire de Nick; cela bénéficierait très probablement de l'utilisation de régresseurs, mais je ne l'ai pas inclus pour l'instant. Et je suis très intéressé de voir ce que vous pouvez faire avec les données! Merci encore.
krcooke
7
" Malheureusement, votre mission est vouée à l'échec puisque vous êtes limité à R et SPSS. " - ce commentaire, malheureusement, va trop loin; n'importe quel langage complet de Turing peut implémenter n'importe quel algorithme écrit dans n'importe quel autre, même s'il est uniquement programmable dans le code machine en basculant les commutateurs et est entièrement implémenté dans Lego. Il n'y a pas de calcul qui puisse être implémenté dans un qui ne puisse pas être fait dans un autre. À moins que vous ne revendiquiez des propriétés magiques pour AUTOBOX, je pense que ce que vous voulez probablement dire est quelque chose comme "déjà disponible en tant que fonctions dans la distribution vanille" comme différence.
Glen_b -Reinstate Monica
@Glen_b Ce que j'aurais pu dire, c'est que la puissance de feu dans les distributions de vanille que vous utilisez est insuffisante pour résoudre le problème à moins que vous n'ayez beaucoup de temps pour écrire de nouvelles procédures.
IrishStat
10

Ce n'est qu'un paquet de commentaires mais ce sera trop long pour ce format. Je ne suis qu'un amateur de séries chronologiques, mais j'ai quelques suggestions simples.

  1. Vous pouvez être sous les ordres ici, mais je pense que cela a besoin d'être affiné en termes de ce que vous attendez de réaliser et de ce qui est le plus important pour vous. La prévision des visites est malheureusement un objectif flou. Par exemple, supposons qu'il soit 16 heures et que vous souhaitiez prévoir les visites une heure à l'avance. Avez-vous vraiment besoin d'un super-modèle intégrant un traitement de toute la série précédente? Cela doit provenir d'une certaine considération des véritables objectifs pratiques et / ou scientifiques, qui peuvent être stipulés par vos supérieurs ou un client ou peuvent être les vôtres en tant que chercheur. Je soupçonne qu'il est plus probable que différents modèles soient nécessaires à des fins différentes.

  2. La séparation des séries horaires semble être motivée par l'idée de réduire le calcul sans trop se soucier de son sens. Donc, l'implication est que vous n'utilisez pas (n'utiliserez pas) des informations plus tôt aujourd'hui pour prédire ce qui se passera à 16 heures, juste toutes les observations précédentes de 16 heures? Il me semble que cela nécessite beaucoup de discussions.

  3. Vous êtes évidemment un apprenant dans les séries chronologiques (et je me mets sur un pied d'égalité) mais aucun apprenant ne devrait commencer avec un problème aussi gros. Vraiment! Vous avez beaucoup de données, vous avez des périodicités à plusieurs échelles, vous avez des irrégularités d'horaires et de jours fériés, vous avez des variables exogènes: vous avez choisi un problème très difficile. (Qu'en est-il aussi des tendances?) C'est facile à dire, mais cela vous a évidemment échappé jusqu'à présent: vous devrez peut-être d'abord travailler sur des versions très simplifiées du problème et avoir une idée de la façon d'adapter des modèles plus simples. Tout jeter dans un grand modèle compliqué ne fonctionne évidemment pas bien, et quelque chose de radicalement plus simple semble nécessaire, ou une prise de conscience que le projet est peut-être trop ambitieux.

Nick Cox
la source
Salut Nick, 1- En effet je suis sous les ordres! Le but est d'essayer de construire un modèle de manière à ce qu'il n'ait pas tendance à surestimer de manière significative (ce qui se traduit par des heures de travail perdues) ou à sous-estimer (afin que le personnel ne soit pas surchargé). 2- J'avais réfléchi à cela, mais je vais creuser plus profondément pour comprendre ce que je gagne / perd de cette façon. Les prévisions comme une série semblaient s'apparenter à un «super modèle», comme vous le dites. 3- Je suis conscient que c'est extrêmement difficile et que je frappe au-dessus de mon poids en ce moment, mais je suis entièrement ouvert à une solution plus simple qui fonctionnera également pour moi ici. Merci beaucoup pour vos pensées, Nick.
krcooke
En termes de solutions plus simples, je ne pouvais pas travailler sur des techniques de lissage exponentiel de telle manière que la période du week-end jubilaire de l'an dernier provoque cette année (même période) une sur-prévision. En raison du type de valeurs aberrantes impliquées, je sentais que je devais absolument utiliser des variables exogènes. Avez-vous d'autres idées à explorer?
krcooke
Tout ce que je peux dire, c'est ce que je ferais si j'étais sous les ordres et si j'avais exactement les informations que vous donnez ici. Mon instinct serait d'abord d'agréger les totaux quotidiens et de travailler avec ceux-ci. C'est déjà assez difficile. C'est beaucoup plus facile d'être critique ici ....
Nick Cox
Salut Nick, ma faute, j'aurais déjà dû dire que j'avais essayé ça. Avec des totaux quotidiens, les résultats semblaient raisonnables. Raisonnable étant le mot clé car, comme vous l'avez dit, vous et Dave, il y a beaucoup plus à considérer ici. Si cela vous intéresse, je peux relancer les données quotidiennes et démontrer qu'elles capturent la saisonnalité hebdomadaire, mensuelle et annuelle. C'est pourquoi j'ai alors pensé à prévoir chaque heure comme une série quotidienne.
krcooke
Un des problèmes que j'ai eu, comme mentionné dans le premier article, est que auto.arima atteint le nombre maximal d'itérations avant de converger, c'est pourquoi j'utilise des paramètres assez généralisés avec Arima (). Tout conseil sur la façon dont je peux surmonter cela serait grandement apprécié!
krcooke