Data.table: fonctions mobiles, agrégats mobiles, fenêtre glissante, moyenne mobile

Implémentation de rollmean proposée, simplifiée.

x = data.table(v1=1:5, v2=1:5)
k = c(2, 3)

i - single column
j - single window
m - int referring to single row
w - current row's sum of rolling window
r - answer for each i, j



md5-be70673ef4a3bb883d4f334bd8fadec9



for i in x
  for j in k
  r = NA_real_
  w = 0
    for m in 1:length(i)
      w = w + i[m]
      w = w - i[m-j]
      r[m] = w / j

oui, et de nombreuses autres fonctions roulées suivent la même idée de base (y compris
écart type glissant/tout moment basé sur les attentes, et toute fonction
comme rollproduct qui utilise inversible * au lieu de + pour agréger au sein
la fenêtre

J'ai toujours envisagé la fonctionnalité de fenêtre mobile en regroupant l'ensemble de données en plusieurs groupes qui se chevauchent (fenêtres). L'API ressemblerait alors à ceci :

DT[i, j,
   by = roll(width=5, align="center")]

Ensuite, si j contient, disons, mean(A) , nous pouvons le remplacer en interne par rollmean(A) -- exactement comme nous le faisons avec gmean() ce moment. Ou j peut contenir une fonctionnalité arbitrairement compliquée (par exemple, exécuter une régression pour chaque fenêtre), auquel cas nous lui fournirions .SD data.table -- exactement comme nous le faisons avec les groupes à l'heure actuelle.

De cette façon, il n'est pas nécessaire d'introduire plus de 10 nouvelles fonctions, une seule. Et l'esprit data.table-y est également ressenti.

Oui d'accord

Le samedi 21 avril 2018, 15h38 Pasha Stetsenko [email protected]
a écrit:

J'ai toujours envisagé la fonctionnalité de fenêtre mobile comme regroupant les
ensemble de données en plusieurs groupes qui se chevauchent (fenêtres). Ensuite, l'API regarderait
quelque chose comme ça:

DT[i, j,
by = roll(width=5, align="center")]

Ensuite, si j contient, disons, moyenne (A), nous pouvons le remplacer en interne par
rollmean(A) -- exactement comme nous le faisons avec gmean() en ce moment. Ou je peux
contenir une fonctionnalité arbitrairement compliquée (par exemple, exécuter une régression pour
chaque fenêtre), auquel cas nous lui fournirions .SD data.table -- exactement
comme nous le faisons avec les groupes en ce moment.

De cette façon, il n'est pas nécessaire d'introduire plus de 10 nouvelles fonctions, une seule. Et cela
se sent data.table-y dans l'esprit aussi.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Rdatatable/data.table/issues/2778#issuecomment-383275134 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AHQQdbADiE4aAI1qPxPnFXUM5gR-0w2Tks5tquH8gaJpZM4TeTQf
.

@st-pasha idée intéressante, ressemble à l'esprit data.table-y, mais elle imposera de nombreuses limitations et n'est pas vraiment appropriée pour cette catégorie de fonctions.

• comment effectuer rollmean par groupe

DT[, rollmean(V1, 3), by=V2]

• comment calculer différentes tailles de fenêtre pour différentes colonnes

DT[, .(rollmean(V1, 3), rollmean(V2, 100))]

• comment calculer rollmean en dehors de [.data.table car nous autorisons maintenant le décalage

rollmean(rnorm(10), 3)

• comment prendre en charge des requêtes telles que

DT[, .(rollmean(list(V1, V2), c(5, 20)), rollmean(list(V2, V3), c(10, 30)))]

• comment appeler mean et rollmean dans le même j appel

DT[, .(rollmean(V1, 3), mean(V1)), by=V2]

Habituellement, lorsque vous utilisez by nous agrégeons les données sur un plus petit nombre de lignes, tandis que les fonctions de roulement renvoient toujours un vecteur de même longueur que l'entrée. Ces types de fonctions dans SQL ont une API dans le style suivant :

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename;

Vous pouvez toujours le combiner avec GROUP BY comme suit :

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename
GROUP BY group_columns;

Donc, en SQL, ces fonctions restent dans SELECT ce qui fait référence à j dans DT.
Dans DT, nous pourrions obtenir la même chose avec :

DT[, rollmean(value, 100)]
DT[, rollmean(value, 100), group_columns]

Les fonctions de roulement entrent dans la même catégorie de fonctions que shift qui renvoie également le même nombre de lignes que celles obtenues en entrée.
Le décalage dans SQL ressemble à :

SELECT LAG(value, 1) OVER ()
FROM tablename;

mean et rollmean ne sont pas seulement des fonctions différentes, ce sont des catégories de fonctions différentes. L'un voulait agréger selon le groupe, un autre pas agréger du tout. Ceci est facilement visible dans SQL où nous n'utilisons pas GROUP BY pour le type de fonctions de roulement mais nous devons utiliser GROUP BY pour des agrégats comme mean (obtenant finalement le total de la subvention lors du regroupement la clause n'est pas présente).
Je ne vois pas de raisonnement solide pour essayer d'appliquer les mêmes règles d'optimisation que nous pour mean , surtout quand cela ne correspond pas vraiment au cas d'utilisation, et tout cela juste pour le bien des données.table-y esprit. La proposition actuelle est également l'esprit data.table-y, il peut facilement être combiné avec := , comme shift . Il ajoute simplement un ensemble de nouvelles fonctions, actuellement non disponibles dans data.table.

@jangorecki Merci, ce sont toutes des considérations valables. Bien sûr, différentes personnes ont des expériences différentes et des points de vue différents sur ce qui devrait être considéré comme « naturel ».

Il est possible d'effectuer rollmean par groupe : il s'agit simplement d'un regroupement à 2 niveaux : DT[, mean(V1), by=.(V2, roll(3))] . Cependant je ne vois pas comment faire différentes tailles de fenêtre sur différentes colonnes avec ma syntaxe...

Je dois admettre que je n'ai jamais vu la syntaxe SQL pour les jointures tournantes auparavant. Il est intéressant de noter qu'ils utilisent un agrégateur standard tel que AVG tout en y appliquant la spécification de fenêtrage. En regardant la documentation Transact-SQL, il y a quelques idées intéressantes, par exemple la distinction entre la sélection de ligne logique/physique. Ils autorisent différents opérateurs "OVER" sur différentes colonnes, mais dans tous les exemples qu'ils donnent, il s'agit de la même clause OVER répétée plusieurs fois. Cela suggère donc que ce cas d'utilisation est beaucoup plus courant, et donc l'utilisation d'un seul groupe roll() entraînerait moins de répétitions.

De plus, cette question SO fournit un aperçu intéressant de la raison pour laquelle la syntaxe OVER a été introduite dans SQL :

Vous pouvez utiliser GROUP BY SalesOrderID. La différence est qu'avec GROUP BY, vous ne pouvez avoir que les valeurs agrégées pour les colonnes qui ne sont pas incluses dans GROUP BY. En revanche, en utilisant des fonctions d'agrégation fenêtrées au lieu de GROUP BY, vous pouvez récupérer à la fois des valeurs agrégées et non agrégées. C'est-à-dire que, bien que vous ne le fassiez pas dans votre exemple de requête, vous pouvez récupérer à la fois les valeurs OrderQty individuelles et leurs sommes, décomptes, moyennes, etc. sur des groupes de mêmes SalesOrderID.

Il semble donc que la syntaxe soit conçue pour contourner la limitation du SQL standard où les résultats de regroupement ne peuvent pas être combinés avec des valeurs non agrégées (c'est-à-dire en sélectionnant à la fois A et mean(A) dans la même expression). Cependant data.table n'a pas une telle limitation, il a donc plus de liberté dans son choix de syntaxe.

Maintenant, si nous voulons vraiment prendre une longueur d'avance, nous devons penser dans une perspective plus large : à quoi servent les fonctions "roulantes", à quoi servent-elles, comment elles peuvent être étendues, etc. Voici mon avis, à venir du point de vue d'un statisticien :

La fonction "Rolling Mean" est utilisée pour lisser certaines entrées bruyantes. Disons, si vous avez des observations dans le temps et que vous voulez avoir une notion de "quantité moyenne", qui varierait néanmoins dans le temps bien que très lentement. Dans ce cas, la « moyenne mobile sur les 100 dernières observations » ou la « moyenne mobile sur toutes les observations précédentes » peuvent être prises en compte. De même, si vous observez une certaine quantité sur une plage d'entrées, vous pouvez la lisser en appliquant une "moyenne mobile sur ±50 observations".

• Ainsi, la première extension consiste à regarder des "fenêtres lisses": imaginez une moyenne sur des observations passées où plus une observation dans le passé est éloignée, moins sa contribution est. Ou une moyenne d'observations proches sur un noyau gaussien.
• Deuxièmement, les fenêtres adaptatives. Par exemple, si vous avez une entrée bruitée définie sur un intervalle [0, 1], le lisser à l'aide d'une fenêtre ±N produit un résultat biaisé près des bords. Un estimateur sans biais adapterait la forme de la fenêtre en fonction de la distance par rapport au bord.
• Lissage de rééchantillonnage : la restriction de produire exactement autant d'observations que dans les données sources est trop restrictive. Si vous considérez vos données comme des observations bruyantes d'une fonction sous-jacente, il est parfaitement raisonnable de demander de calculer les valeurs lissées de cette fonction sur un maillage plus grossier/plus fin que l'entrée d'origine. Ou peut-être que les données d'origine sont espacées de manière irrégulière et que vous souhaitez les rééchantillonner sur une grille régulière.
• Jackknife : pour chaque observation, vous souhaitez calculer la moyenne/régression sur toutes les observations à l'exception du courant.
• Division en K : affichez les données sous forme de groupes multiples, chaque groupe n'excluant qu'une petite partie des observations.

Tous ces éléments peuvent être implémentés en tant qu'opérateurs de regroupement étendus, les fenêtres mobiles n'étant qu'un des éléments de cette liste. Cela étant dit, je ne comprends pas pourquoi nous ne pouvons pas jouer sur les deux tableaux.

Je dois admettre que je n'ai jamais vu la syntaxe SQL pour les jointures tournantes auparavant.

Je suppose que vous voulez dire des fonctions de roulement, le problème n'a rien à voir avec les jointures de roulement.

Ils autorisent différents opérateurs "OVER" sur différentes colonnes, mais dans tous les exemples qu'ils donnent, il s'agit de la même clause OVER répétée plusieurs fois. Cela suggère donc que ce cas d'utilisation est beaucoup plus courant et que l'utilisation d'un seul groupe roll() entraînerait donc moins de répétitions.

C'est juste une question de cas d'utilisation, si vous appelez le même OVER() plusieurs fois, vous trouverez peut-être plus performant d'utiliser GROUP BY , de créer une table de recherche et de la réutiliser dans d'autres requêtes. Quels que soient les exemples, il est nécessaire de répéter OVER() pour conserver la caractéristique de localité pour chaque mesure fournie. Mes cas d'utilisation des entrepôts de données n'étaient pas aussi simples que ceux des documents Microsoft.

En revanche, en utilisant des fonctions d'agrégation fenêtrées au lieu de GROUP BY, vous pouvez récupérer à la fois des valeurs agrégées et non agrégées.

Dans data.table, nous faisons := et by en une seule requête pour y parvenir.

Il apparaît donc que la syntaxe est conçue pour contourner la limitation du SQL standard où les résultats de regroupement ne peuvent pas être combinés avec des valeurs non agrégées (c'est-à-dire en sélectionnant à la fois A et moyenne(A) dans la même expression). Cependant data.table n'a pas une telle limitation, il a donc plus de liberté dans son choix de syntaxe.

Ce n'est pas une grande limitation de SQL mais juste la conception de GROUP BY, qu'il agrégera, de la même manière que nos agrégats by . Une nouvelle API était nécessaire pour couvrir les nouvelles fonctionnalités de la fenêtre. Le regroupement pour la fonction de fenêtre SQL peut être fourni pour chaque appel de fonction à l'aide de FUN() OVER (PARTITION BY ...) où _partition by_ est comme un regroupement local pour une seule mesure. Donc, pour obtenir la flexibilité de SQL, nous aurions besoin d'utiliser j = mean(V1, roll=5) ou j = over(mean(V1), roll=5) gardant cette API dans j . Néanmoins, cette approche ne permettra pas de prendre en charge tous les cas d'utilisation mentionnés ci-dessus.

vous pouvez le lisser en appliquant une "moyenne glissante sur ±50 observations".

C'est à cela que sert l'argument align .

Ainsi, la première extension consiste à regarder des "fenêtres lisses": imaginez une moyenne sur des observations passées où plus une observation dans le passé est éloignée, moins sa contribution est. Ou une moyenne d'observations proches sur un noyau gaussien.

Il existe de nombreuses variantes (nombre pratiquement illimité) de moyennes mobiles, la fonction de fenêtre de lissage la plus courante (autre que rollmean/SMA) est la moyenne mobile exponentielle (EMA). Ce qui devrait être inclus, et ce qui ne l'est pas, n'est pas trivial à décider, et il est en fait préférable de prendre cette décision en fonction des demandes de fonctionnalités qui viendront des utilisateurs, jusqu'à présent, aucune demande de ce type n'a été demandée.

Tous ces éléments peuvent être implémentés en tant qu'opérateurs de regroupement étendus, les fenêtres mobiles n'étant qu'un des éléments de cette liste.

Certes, ils le peuvent, mais si vous regardez SO et les problèmes créés dans notre référentiel, vous verrez que ces quelques fonctions de roulement ici sont responsables de 95+% des demandes des utilisateurs. Je suis heureux de travailler sur EMA et d'autres MA (bien que je ne sois pas sûr que data.table soit le meilleur endroit pour ceux-ci), mais en tant que problème distinct. Certains utilisateurs, moi inclus, attendent une simple moyenne mobile dans data.table depuis déjà 4 ans.

Voici mon avis, venant du point de vue d'un statisticien

Mon point de vue vient du Data Warehousing (où j'ai utilisé la fonction fenêtre, au moins une fois par semaine) et de l'analyse des tendances des prix (où j'ai utilisé des dizaines de moyennes mobiles différentes).

rollmean brouillon de roll . J'ai trouvé que la plupart des autres packages qui implémentent la moyenne mobile ne sont pas capables de bien gérer les na.rm=FALSE et les NA présents dans l'entrée. Cette implémentation gère NA de manière cohérente jusqu'à mean , ce qui impose une surcharge supplémentaire en raison des appels ISNAN . Nous pourrions autoriser l'API à une version plus rapide mais moins sûre si l'utilisateur est sûr qu'il n'y a pas de NA en entrée.
PR est en #2795

@mattdowle répondant aux questions des relations publiques

Pourquoi faisons-nous cela dans data.table ? Pourquoi l'intégrons-nous au lieu de contribuer aux packages existants et de les utiliser à partir de data.table ?

1. Il y a eu 3 problèmes différents créés pour demander cette fonctionnalité dans data.table. Également plusieurs questions SO étiquetées data.table. Les utilisateurs s'attendent à ce que cela soit dans la portée de data.table.
2. data.table s'adapte parfaitement aux données de séries chronologiques et les agrégats glissants sont des statistiques assez utiles là-bas.

je suppose que cela se résume à la syntaxe (fonctionnalités possibles ou pratiques uniquement si elles sont intégrées à data.table ; par exemple, à l'intérieur [...] et optimisées) et à la construction des éléments internes de data.table dans la fonction de roulement au niveau C ; Par exemple, froll* doit être conscient et utiliser les indices et la clé data.table. Si c'est le cas, plus de détails à ce sujet sont nécessaires ; par exemple un court exemple simple.

Pour moi personnellement c'est une question de vitesse et de manque de chaîne de dépendances, aujourd'hui pas facile à réaliser.
Les clés/indices peuvent être utiles pour frollmin/frollmax, mais il est peu probable que l'utilisateur crée un index sur la variable de mesure. Il est peu probable que l'utilisateur fasse un index sur la variable de mesure, nous n'avons pas encore fait cette optimisation pour min/max. Je ne vois pas beaucoup de sens pour l'optimisation GForce car la mémoire allouée n'est pas libérée après l'appel roll* mais renvoyée en tant que réponse (par opposition à la moyenne non glissante, à la somme, etc.).

S'il n'y a pas d'argument convaincant pour l'intégration, alors nous devrions plutôt contribuer aux autres packages.

J'en ai énuméré quelques-uns ci-dessus, si vous n'êtes pas convaincu, je vous recommande de remplir une question aux utilisateurs de data.table, de demander sur twitter, etc. pour vérifier la réponse. Cette fonctionnalité était demandée depuis longtemps et par de nombreux utilisateurs. Si la réponse ne vous convainc pas, vous pouvez fermer ce problème.

J'ai trouvé que sparklyr peut très bien prendre en charge les fonctions de roulement dans un ensemble de données à très grande échelle.

@harryprince pourrait mettre un peu plus de lumière en fournissant un exemple de code de la façon dont vous le faites dans sparklyr ?
Selon "Fonctions de fenêtre" dplyr vignette

Les agrégats roulants fonctionnent dans une fenêtre de largeur fixe. Vous ne les trouverez pas dans la base R ou dans dplyr, mais il existe de nombreuses implémentations dans d'autres packages, tels que RcppRoll.

AFAIU, vous utilisez une API Spark personnalisée via sparklyr pour laquelle l'interface dplyr n'est pas implémentée, n'est-ce pas ?

Ce problème concerne les agrégats roulants, d'autres "types" de fonctions de fenêtre sont déjà dans data.table depuis longtemps.

Fournir un exemple afin que nous puissions comparer les performances (en mémoire) par rapport à sparklyr / SparkR serait également utile.

Il m'est juste venu à l'esprit que cette question:

comment calculer différentes tailles de fenêtre pour différentes colonnes ?

a en fait une portée plus large, et ne s'applique pas uniquement aux fonctions de roulement.

Par exemple, il semble parfaitement raisonnable de demander comment sélectionner le prix moyen d'un produit par date, puis par semaine, puis peut-être par semaine+catégorie, le tout dans la même requête. Si jamais nous devions implémenter une telle fonctionnalité, la syntaxe naturelle pour cela pourrait être

DT[, .( mean(price, by=date), 
        mean(price, by=week), 
        mean(price, by=c(week, category)) )]

Maintenant, si cette fonctionnalité avait déjà été implémentée, cela aurait été un simple saut à partir de là vers des moyens de roulement :

DT[, .( mean(price, roll=5), 
        mean(price, roll=20), 
        mean(price, roll=100) )]

Je ne dis pas que c'est sans équivoque mieux que rollmean(price, 5) - je propose juste quelques alternatives à considérer...

@st-pacha

comment sélectionner le prix moyen du produit par date, puis par semaine, puis peut-être par semaine + catégorie - le tout dans la même requête.

AFAIU, cela est déjà possible en utilisant ?groupingsets , mais pas encore connecté à [.data.table .

@jangorecki , @st-pasha , and Co. -- Merci pour tout votre travail sur ce sujet ! Je suis curieux de savoir pourquoi la prise en charge partielle des fenêtres a été supprimée de la portée, est-il possible que cette fonctionnalité revienne sur la feuille de route ? Cela me serait parfois utile et comblerait une lacune de fonctionnalité qui, à ma connaissance, n'a pas été comblée soit zoo ou RcppRoll .

Cette question de débordement de pile est un bon exemple d'une application continue qui pourrait bénéficier d'un argument partial = TRUE .

@msummersgill Merci pour vos commentaires. Dans le premier article, j'ai explicitement lié commit sha où le code de fonction de fenêtre partielle peut être trouvé. L'implémentation qui s'y trouve a ensuite été supprimée pour réduire la complexité du code. Il imposait également un faible coût de performance même lorsqu'il n'utilisait pas cette fonctionnalité. Cette fonctionnalité peut (et devrait probablement) être implémentée dans l'autre sens, d'abord complétée telle quelle, puis remplissez simplement la fenêtre partielle manquante à l'aide d'une boucle supplémentaire de 1:window_size . Ainsi, la surcharge de cette fonctionnalité n'est perceptible que lorsque vous l'utilisez. Néanmoins, nous fournissons cette fonctionnalité via l'argument adaptive , où la fonctionnalité partial n'est qu'un cas particulier de la moyenne mobile adaptive . Il y a un exemple comment réaliser partial utilisant adaptive dans ?froll manual . Collez-le ici :

d = as.data.table(list(1:6/2, 3:8/4))
an = function(n, len) c(seq.int(n), rep(n, len-n))
n = an(3, nrow(d))
frollmean(d, n, adaptive=TRUE)

Bien sûr, ce ne sera pas aussi efficace que la fonction de roulement non adaptative utilisant une boucle supplémentaire pour remplir une fenêtre partielle.
AFAIK zoo a une fonction partial .

Avez-vous l'intention d'ajouter des fonctions de régression glissante à data.table ?

@waynelapierre s'il y aura une demande pour ça, alors oui. tu as mon +1

merci c'est super. Juste une question cependant. Je ne vois que des agrégats roulants simples, comme un moyen roulant ou une médiane roulante. Implémentez-vous également des fonctions de roulement plus raffinées telles que des trames de données DT de roulement ? Dites, créez un DT roulant en utilisant les 10 derniers obs et exécutez une régression lm dessus.

Merci!

@randomgambit Je dirais que c'est hors de portée, à moins qu'il n'y ait une forte demande pour cela. Il ne serait pas très difficile de le faire pour être plus rapide que la base R/zoo simplement en gérant la boucle imbriquée en C. Mais nous devrions essayer de l'implémenter en utilisant l'algorithme "en ligne", pour éviter la boucle imbriquée. C'est plus délicat, et nous pourrions éventuellement le faire pour n'importe quelle statistique, nous devons donc supprimer ces statistiques à un moment donné.

@jangorecki intéressant merci. Cela signifie que je vais continuer à utiliser tsibble pour intégrer... DATA.TABLES dans un tibble ! époustouflant :D

J'ai essayé d'utiliser frollmean pour calculer une "courbe logistique" non paramétrique qui montre P[y | x] pour le binaire y utilisant les voisins les plus proches de x . A été surpris que y stocké en tant que logical n'ait pas été converti automatiquement en integer :

DT = data.table(x = rnorm(1000), y = runif(1000) > .5)
DT[order(x), .(x, p_y = frollmean(y, 50L))]

Erreur dans froll(fun = "mean", x = x, n = n, fill = fill, algo = algo, align = align, :
x doit être de type numérique

Un exemple de la façon dont les arguments vectorisés x / n peuvent avoir un impact sur les performances.
https://github.com/AdrianAntico/RemixAutoML/commit/d8370712591323be01d0c66f34a70040e2867636#r34784427
moins de boucles, code plus facile à lire, beaucoup plus rapide (accélération 10x-36x).

prêt pour frollapply : https://github.com/Rdatatable/data.table/pull/3600

    ### fun             mean     sum  median
    # rollfun          8.815   5.151  60.175
    # zoo::rollapply  34.373  27.837  88.552
    # zoo::roll[fun]   0.215   0.185      NA
    # frollapply       5.404   1.419  56.475
    # froll[fun]       0.003   0.002      NA

salut les gars, est-ce que FUN (défini par l'utilisateur) transmis à frollapply sera modifié pour renvoyer un objet R ou data.frame (data.table), x transmis à frollapply pourrait être data.table de caractère non contraint en numérique, alors FUN pourrait le faire labels et frollapply renvoient une liste ? Ensuite, nous pouvons effectuer des tests de régression ou de roulement, comme les tests de Benford ou le résumé sur les étiquettes.

Il est toujours utile de fournir un exemple reproductible. Pour clarifier... dans un tel scénario, vous voudriez frollapply(dt, 3, FUN) renvoyer une liste de longueur nrow(dt) où chaque élément de la liste sera data.table renvoyé par FUN(dt[window]) ?
frollapply(x=dt, n=3, fun=FUN)[[3]] équivaut à FUN(dt[1:3])
frollapply(x=dt, n=3, FUN=FUN)[[4]] équivaut à FUN(dt[2:4])
Est-ce exact? @jerryfuyu0104

Actuellement, nous prenons en charge plusieurs colonnes passées au premier argument, mais nous les traitons séparément, en boucle. Nous aurions probablement besoin d'un argument supplémentaire multi.var=FALSE , lorsqu'il est défini sur true, il ne bouclerait pas sur x (comme il le fait maintenant : list(FUN(x[[1]]),FUN(x[[2]])) ) mais transmettrait toutes les colonnes FUN(x) .

une mise à jour pour cela?

J'appuie cette demande précédente.

De plus, serait-il possible de soutenir un argument « partiel » pour autoriser des fenêtres partielles ?

@eliocamp pouvez-vous préciser ce qu'est une fenêtre partial ?

@eliocamp il serait possible de soutenir l'argument "partiel". Vous le savez peut-être déjà, mais la prise en charge de cette fonctionnalité existe déjà, en utilisant l'argument adaptive=TRUE , voir les exemples pour plus de détails.

Cela signifierait calculer la fonction du début à la fin au lieu de former le point de la demi-fenêtre.
Par exemple, pour une moyenne mobile de largeur 11, le premier élément renvoyé serait la moyenne des éléments 1 à 6. Le second, la moyenne du 1er au 7e, et ainsi de suite.

@jangorecki oh merci, je ne le savais pas ! Je vérifierai.

D'accord, nous avons besoin d'un argument partiel, non seulement pour la commodité mais aussi pour la vitesse. adaptive=TRUE ajoute un surcoût.
Et oui, nous avons également besoin d'une régression glissante, donc de fournir plusieurs variables et de les appliquer à la fois, pas chacune séparément.
Il n'y a pas de mise à jour sur l'état de ceux-ci.

J'aimerais aider, mais mes compétences en C++ sont totalement inexistantes. :sweat: Pensez-vous que cela pourrait convenir aux débutants complets ?

Nous ne coderons pas en C++ mais en C. Oui, c'est un bon point de départ. J'ai fait exactement cela sur frollmean.

Je regarde le code et il semble intimidant. Mais je vous tiendrai au courant dans tous les cas.

Mais maintenant, pour une autre requête : frollmean(.SD) doit conserver les noms. Plus généralement, froll* doit conserver les noms si l'entrée est une liste avec des noms.

En tant qu'utilisateur fréquent de data.table, je trouve extrêmement utile d'avoir des fonctionnalités « sensibles au temps », comme celles actuellement proposées dans le package tsibble . Malheureusement, ce paquet est développé autour de dplyr . Je me demande si une implémentation data.table pourrait être possible. Les fonctions de fenêtre proposées dans ce numéro sont un sous-ensemble de ces fonctionnalités.

@ywhcuhk Merci pour vos commentaires, je pensais en fait que ce problème en demandait déjà trop. La majeure partie de cela est bien couverte par un rouleau d' emballage encore léger qui est très rapide. En ce qui concerne les autres fonctionnalités, je suggère de créer un nouveau problème pour chaque fonctionnalité qui vous intéresse, de sorte que la discussion pour savoir si nous voulons implémenter/maintenir peut être décidée pour chacune séparément. Rien qu'en regardant le fichier readme de tstibble, je ne vois rien de nouveau qu'il offre...
Son titre est "Tidy Temporal Data Frames" mais il ne semble même pas offrir de jointures temporelles.

Merci @jangorecki pour la réponse. C'est peut-être un problème dépendant du contexte. La structure de données avec laquelle je traite le plus souvent est connue sous le nom de « données de panneau », avec un identifiant et une heure. Si le programme est "conscient" de cette fonctionnalité de données, de nombreuses opérations, en particulier les opérations de séries chronologiques, seront rendues très faciles. Pour quelqu'un qui connaît STATA, ce sont les opérations basées sur tsset et xtset , telles que lead, lag, fill gap, etc. Je pense que "l'index" dans la data.table peut être amélioré d'une manière ou d'une autre pour permettre de telles opérations.

Bien sûr, ces opérations peuvent être effectuées dans des fonctions data.table comme shift et by . Je pensais juste que le index dans data.table avait beaucoup de potentiel à explorer. Je suis d'accord que cela devrait appartenir à un autre problème. Mais je ne sais pas comment le déplacer sans perdre les discussions ci-dessus...