Data.table: ローリング関数、ローリングアグリゲート、スライディングウィンドウ、移動平均

提案されたrollmean実装、簡略化。

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

はい、そしてさらに多くのロール関数が同じ基本的な考え方に従います（
ローリング標準偏差/期待値ベースのモーメント、および関数
+の代わりに反転可能な*を使用して内部で集約するrollproductのように
窓

私は常に、データセットを複数の重複するグループ（ウィンドウ）にグループ化することとして、ローリングウィンドウ機能を想定していました。 その場合、APIは次のようになります。

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

次に、 jにmean(A) jが含まれている場合、現在gmean()行っているのとまったく同じように、内部でrollmean(A)置き換えることができます。 または、 j任意の複雑な機能を含めることができます（たとえば、ウィンドウごとに回帰を実行します）。その場合、グループの場合とまったく同じように、 .SD data.tableを提供します。たった今。

このように、10以上の新しい機能を導入する必要はありません。1つだけです。 そして、それは精神的にもdata.table-yを感じます。

はい同意する

土、2018年4月21日には、15:38パシャStetsenko [email protected]
書きました：

私は常にローリングウィンドウ機能をグループ化することを想定していました
データセットを複数の重複するグループ（ウィンドウ）に分割します。 次に、APIは次のようになります
このようなもの：

DT [i、j、
by = roll（width = 5、align = "center"）]

次に、jにたとえばmean（A）が含まれている場合、内部的にそれを次のように置き換えることができます。
rollmean（A）-現在gmean（）で行っているのとまったく同じです。 またはjはできます
任意に複雑な機能が含まれている（たとえば、
各ウィンドウ）、この場合、.SDdata.tableを提供します-正確に
今のグループと同じように。

このように、10以上の新しい機能を導入する必要はありません。1つだけです。 そしてそれ
data.table-yの精神も感じます。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Rdatatable/data.table/issues/2778#issuecomment-383275134 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AHQQdbADiE4aAI1qPxPnFXUM5gR-0w2Tks5tquH8gaJpZM4TeTQf
。

@ st-pashaの興味深いアイデアは、data.table-yの精神のように見えますが、多くの制限が課せられ、このカテゴリの関数にはあまり適していません。

• グループごとにrollmeanを実行する方法

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

• さまざまな列のさまざまなウィンドウサイズを計算する方法

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

• シフトを許可するため、 [.data.table外側でrollmeanを計算する方法

rollmean(rnorm(10), 3)

• 次のようなクエリをサポートする方法

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

• 同じj呼び出しでmeanとrollmeanを呼び出す方法

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

通常、 byを使用する場合、データをより少ない行数に集約しますが、ローリング関数は常に入力と同じ長さのベクトルを返します。 SQLのこのタイプの関数には、次のスタイルのAPIがあります。

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

次のように、それをGROUPBYと組み合わせることができます。

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

したがって、SQLでは、これらの関数はDTのjを参照するSELECT留まります。
DTでは、次の方法で同じことを実現できます。

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

ローリング関数は、 shiftと同じカテゴリの関数に当てはまり、入力と同じ数の行を返します。
SQLのシフトは次のようになります。

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

meanとrollmeanは単なる異なる関数ではなく、異なるカテゴリの関数です。 1つはグループごとに集約することを意味し、もう1つはまったく集約しないことを意味します。 これは、ローリング関数タイプにGROUP BYを使用しないSQLで簡単に確認できますが、 meanような集計にはGROUP BYを使用する必要があります（最終的にはグループ化時に助成金の合計を取得します）句は存在しません）。
mean場合と同じ最適化ルールを適用しようとする強い理由は見当たりません。特に、ユースケースに実際に適合しない場合は、data.table-yのためだけです。精神。 現在の提案はdata.table-yの精神でもあり、 shiftと同じように、 :=と簡単に組み合わせることができます。 現在data.tableでは使用できない新しい関数のセットを追加するだけです。

@jangoreckiありがとう、これらはすべて有効な考慮事項です。 もちろん、人によって経験や見方が異なり、何を「自然」と見なすべきかについても異なります。

グループごとにrollmeanを実行することができます。これは2レベルのグループ化です： DT[, mean(V1), by=.(V2, roll(3))] 。 しかし、私の構文で異なる列に異なるウィンドウサイズを作成する方法がわかりません...

ローリング結合のSQL構文を見たことがないことを認めなければなりません。 彼らがAVGなどの標準的なアグリゲーターを使用しているにもかかわらず、ウィンドウ仕様を適用しているのは興味深いことです。 Transact-SQLのドキュメントを見ると、論理行と物理行の選択の違いなど、興味深いアイデアがいくつかありroll()グループを使用すると繰り返しが少なくなることを示唆しています。

また、このSOの質問は、なぜOVER構文がSQLに導入されたのかという興味深い洞察を提供します。

GROUP BYSalesOrderIDを使用できます。 違いは、GROUP BYでは、GROUPBYに含まれていない列の集計値のみを持つことができることです。 対照的に、GROUP BYの代わりにウィンドウ集計関数を使用すると、集計値と非集計値の両方を取得できます。 つまり、サンプルクエリではこれを行っていませんが、同じSalesOrderIDのグループについて、個々のOrderQty値とそれらの合計、カウント、平均などの両方を取得できます。

したがって、構文は、group-byの結果を集計されていない値と組み合わせることができない標準SQLの制限を回避するように設計されているようです（つまり、同じ式でAとmean(A)両方を選択します）。 ただし、 data.tableはそのような制限がないため、構文の選択に自由度があります。

さて、本当に時代を先取りしたいのであれば、より広い視点で考える必要があります。「ローリング」機能とは何か、それらは何に使用されるのか、どのように拡張できるのかなどです。統計家の観点から：

「移動平均」関数は、ノイズの多い入力を平滑化するために使用されます。 たとえば、時間の経過に伴う観測があり、「平均量」の概念が必要な場合、それでも非常にゆっくりではありますが、時間の経過とともに変化します。 この場合、「過去100回の観測の移動平均」または「以前のすべての観測の移動平均」を考慮することができます。 同様に、入力の範囲で特定の量を観測する場合は、「±50回の観測を超える移動平均」を適用することでそれを平滑化できます。

• したがって、最初の拡張は「滑らかなウィンドウ」を調べることです。過去の観測の平均を想像してください。過去の観測が進むほど、その寄与は少なくなります。 または、ガウスカーネルでの近くの観測値の平均。
• 2番目はアダプティブウィンドウです。 たとえば、間隔[0、1]にわたって定義されたノイズの多い入力がある場合、±Nウィンドウを使用してそれを平滑化すると、エッジの近くに偏った結果が生成されます。 不偏推定量は、エッジからの距離に基づいてウィンドウの形状を適応させます。
• リサンプル平滑化：ソースデータとまったく同じ数の観測値を生成するための制限が制限されすぎています。 データを基礎となる関数のノイズの多い観測値と考える場合は、元の入力よりも粗い/細かいメッシュでその関数の平滑化された値を計算するように依頼するのが完全に合理的です。 または、元のデータの間隔が不規則で、通常のグリッドにリサンプリングしたい場合もあります。
• ジャックナイフ：各観測値について、現在を除くすべての観測値の平均/回帰を計算します。
• K分割：データを複数のグループとして表示します。各グループは、観測値のごく一部のみを除外します。

これらはすべて拡張グループ化演算子として実装でき、ローリングウィンドウはこのリストの要素の1つにすぎません。 そうは言っても、私たちがそれを両方の方法で持つことができない理由はありません。

ローリング結合のSQL構文を見たことがないことを認めなければなりません。

私はあなたがローリング関数を意味していると思います、問題はローリング結合とは何の関係もありません。

これらは、異なる列で異なる「OVER」演算子を許可しますが、それらが示すすべての例では、同じOVER句が複数回繰り返されます。 したがって、このユースケースははるかに一般的であり、したがって、単一のroll（）グループを使用すると繰り返しが少なくなることを示唆しています。

同じOVER（）を何度も呼び出す場合は、 GROUP BY使用し、ルックアップテーブルを作成して、他のクエリで再利用する方がパフォーマンスが高い場合があります。 例が何であれ、提供された各メジャーの局所性の特徴を保持するには、OVER（）を繰り返す必要があります。 私のユースケースは、Microsoftドキュメントのユースケースほど単純ではないデータウェアハウスのユースケースです。

対照的に、GROUP BYの代わりにウィンドウ集計関数を使用すると、集計値と非集計値の両方を取得できます。

data.tableでは、1つのクエリで:=とbyを実行してそれを実現します。

したがって、構文は、group-byの結果を集計されていない値と組み合わせることができない（つまり、同じ式でAとmean（A）の両方を選択する）標準SQLの制限を回避するように設計されているようです。 ただし、data.tableにはそのような制限がないため、構文の選択に自由度があります。

SQLの制限はそれほど多くありませんが、 by集約されるのと同じ方法で集約されるのは、GROUPBYの設計だけです。 新しいウィンドウ機能をカバーするには、新しいAPIが必要でした。 SQLウィンドウ関数のグループ化は、 FUN() OVER (PARTITION BY ...)を使用して関数呼び出しごとに提供できます。ここで、_partition by_は、単一メジャーのローカルグループ化のようなものです。 したがって、SQLの柔軟性を実現するには、 j = mean(V1, roll=5)またはj = over(mean(V1), roll=5)を使用して、そのAPIをj維持する必要があります。 それでも、このアプローチでは、上記のすべてのユースケースをサポートできるわけではありません。

「±50回以上の観測値の移動平均」を適用することで、それを滑らかにすることができます。

これは、 align引数が使用される目的です。

したがって、最初の拡張は「滑らかなウィンドウ」を調べることです。過去の観測の平均を想像してください。過去の観測が進むほど、その寄与は少なくなります。 または、ガウスカーネルでの近くの観測値の平均。

移動平均には多くのバリエーション（事実上無制限の数）があり、最も一般的な平滑化ウィンドウ関数（rollmean / SMA以外）は指数移動平均（EMA）です。 どちらを含めるべきか、どれを含めないかを決定するのは簡単ではなく、実際には、ユーザーからの機能要求に従ってその決定を行うのが最善です。これまでのところ、このような要求はありませんでした。

これらはすべて拡張グループ化演算子として実装でき、ローリングウィンドウはこのリストの要素の1つにすぎません。

確かに可能ですが、SOとリポジトリで作成された問題を見ると、ここにあるいくつかのローリング関数がユーザーからのリクエストの95％以上を占めていることがわかります。 EMAやその他のMAに取り組んで満足しています（data.tableがそれらに最適かどうかはわかりませんが）が、別の問題としてです。 私を含め、一部のユーザーは、data.tableでの単純な移動平均をすでに4年間待っています。

これが私の見解です。統計家の視点から来ています。

私の視点は、データウェアハウジング（ウィンドウ関数を少なくとも週に1回使用した）と価格傾向分析（数十の異なる移動平均を使用した）から来ています。

rollmeanドラフトはrollブランチにプッシュされます。 移動平均を実装する他のパッケージのほとんどは、入力に存在するna.rm=FALSEとNAをうまく処理できないことがわかりました。 この実装は、NAを一貫してmeanに処理します。これにより、 ISNAN呼び出しのために、追加のオーバーヘッドが発生します。 ユーザーが入力にNAがないと確信している場合は、APIのバージョンを高速化することはできますが、安全性は低くなります。
PRは＃2795にあります

PRからの質問に答える@mattdowle

data.table内でこれを行うのはなぜですか？ 既存のパッケージに貢献してdata.tableからそれらを使用するのではなく、なぜそれを統合するのですか？

1. data.tableでその機能を要求する3つの異なる問題が作成されました。 また、複数のSO質問がdata.tableにタグ付けされています。 ユーザーは、それがdata.tableの範囲内にあることを期待しています。
2. data.tableは時系列データに完全に適合し、ローリングアグリゲートは非常に有用な統計です。

私の推測では、構文（data.tableに組み込まれている場合にのみ可能または便利な機能。たとえば[...]内で最適化されている）と、data.tableの内部をCレベルのローリング関数に組み込むことになります。 たとえば、froll *は、data.tableインデックスとキーを認識して使用する必要があります。 もしそうなら、それに関するより詳細な情報が必要です。 たとえば、簡単な短い例。

私個人としては、スピードと依存関係の連鎖の欠如が問題であり、今日では簡単に達成することはできません。
キー/インデックスはfrollmin / frollmaxに役立つ可能性がありますが、ユーザーがメジャー変数にインデックスを作成する可能性はほとんどありません。 ユーザーがメジャー変数のインデックスを作成する可能性はほとんどありません。また、この最小/最大の最適化はまだ行っていません。 割り当てられたメモリはroll *呼び出し後に解放されず、応答として返されるため（非移動平均、合計などとは対照的に）、GForce最適化にはあまり意味がありません。

統合するための説得力のある議論がない場合は、代わりに他のパッケージに貢献する必要があります。

上記のいくつかをリストしましたが、確信が持てない場合は、data.tableユーザーに質問を入力するか、Twitterなどで回答を確認することをお勧めします。 この機能は長い間、多くのユーザーから要求されていました。 応答しても納得できない場合は、この問題を解決できます。

sparklyrは、非常に大規模なデータセットでローリング関数を非常にうまくサポートできることがわかりました。

@harryprinceは、sparklyrでそれを行う方法のサンプルコードを提供することで、もう少し光を
「ウィンドウ関数」によると

ローリングアグリゲートは、固定幅のウィンドウで動作します。 ベースRやdplyrにはありませんが、RcppRollなどの他のパッケージには多くの実装があります。

dplyrインターフェースが実装されていないsparklyrを介してカスタムsparkAPIを使用しているAFAIU、正しいですか？

この問題はローリングアグリゲートに関するものであり、他の「タイプ」のウィンドウ関数はすでに長い間data.tableにあります。

（メモリ内の）パフォーマンスとsparklyr / SparkRを比較できるように、いくつかの例を提供することも役立ちます。

この質問が私に思い浮かびました：

異なる列の異なるウィンドウサイズを計算する方法は？

実際にはより広い範囲を持っており、ローリング関数にのみ適用されるわけではありません。

たとえば、同じクエリ内で、日付、週、場合によっては週とカテゴリで平均商品価格を選択する方法を尋ねるのは完全に合理的であるように思われます。 そのような機能を実装する場合、その自然な構文は次のようになります。

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

さて、この機能がすでに実装されていれば、そこからローリング手段への単純な飛躍でした。

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

これがrollmean(price, 5)よりも明らかに優れていると言っているわけではありません-考慮すべきいくつかの選択肢を投入するだけです...

@ st-pasha

日付、週、そしておそらく週とカテゴリで平均製品価格を選択する方法-すべて同じクエリ内で。

AFAIUこれは?groupingsetsを使用してすでに可能ですが、まだ[.data.table接続されていません。

@ jangorecki 、@ st-pasha、およびzooまたはRcppRollどちらにも埋められていない機能のギャップを埋めます。

このStackOverflowの質問は、 partial = TRUE引数の恩恵を受ける可能性のあるローリングアプリケーションの良い例です。

@msummersgillフィードバックをありがとう。 最初の投稿では、部分的なウィンドウ機能コードが見つかるコミットshaを明示的にリンクしました。 そこにある実装は、コードの複雑さを軽減するために後で削除されました。 また、その機能を使用しなくても、パフォーマンスコストが低くなりました。 この機能は、他の方法で実装できます（おそらく、実装する必要があります）。最初はそのまま完了し、次に1:window_size追加ループを使用して、欠落している部分ウィンドウを埋めます。 したがって、その機能のオーバーヘッドは、それを使用した場合にのみ顕著になります。 それでも、 adaptive引数を介してその機能を提供します。ここで、 partial機能は、 adaptive平均の特殊なケースにすぎません。 ?frollマニュアルにadaptiveを使用してpartialを達成する方法の例があります。 ここに貼り付けます：

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)

もちろん、余分なループを使用してウィンドウの一部だけを埋める非適応ローリング関数ほど効率的ではありません。
AFAIK zooはpartial機能があります。

data.tableにローリング回帰関数を追加する計画はありますか？

@waynelapierreそれに対する需要があるなら、そうです。 あなたは私の+1を持っています

ありがとうこれは素晴らしいです。 ただし、質問は1つだけです。 移動平均や移動中央値などの単純なローリング骨材しか表示されません。 ローリングDTデータフレームなどのより洗練されたローリング機能も実装していますか？ たとえば、最後の10個のobsを使用してローリングDTを作成し、それにlm回帰を実行します。

ありがとう！

@randomgambit需要が高くない限り、範囲外だと思います。 Cでネストされたループを処理するだけで、ベースR / zooよりも高速にすることはそれほど難しくありません。ただし、ネストされたループを回避するには、「オンライン」アルゴリズムを使用して実装する必要があります。 これはよりトリッキーであり、最終的には任意の統計に対してそれを行うことができるため、ある時点でそれらの統計を遮断する必要があります。

@jangorecki興味深いありがとう。 つまり、 tsibbleを使用して埋め込みます... DATA.TABLESをtibble ！ マインドブロー：D

frollmeanを使用して、 x最近傍を使用してバイナリy P[y | x]を示すノンパラメトリック「ロジスティック曲線」を計算しようとしました。 logicalがinteger自動的にキャストされなかったため、 y保存されていることに驚きました：

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

froll（fun = "mean"、x = x、n = n、fill = fill、algo = algo、align = align 、：のエラー
xは数値型である必要があります

ベクトル化されたx / n引数がパフォーマンスにどのように影響するかの例。
https://github.com/AdrianAntico/RemixAutoML/commit/d8370712591323be01d0c66f34a70040e2867636#r34784427
ループが少なく、コードが読みやすく、はるかに高速です（10倍から36倍の高速化）。

frollapply準備完了： https ：

    ### 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

こんにちはみんな、frollapplyに渡されたFUN（ユーザー定義）はRオブジェクトまたはdata.frame（data.table）を返すように変更されますか？frollapplyに渡されたxは数値に強制されていない文字のdata.tableである可能性があります。ラベルとfrollapplyはリストを返しますか？ 次に、ベンフォードのテストやラベルの要約を行うように、ローリング回帰またはローリングテストを行うことができます。

再現可能な例を提供することは常に有用です。 ...明確にするために、このようなシナリオでは、あなたがしたいと思いますfrollapply(dt, 3, FUN)長さのリストを返すnrow(dt)の各リスト要素は次のようになりますどこdata.tableによって返さFUN(dt[window]) ？
frollapply(x=dt, n=3, fun=FUN)[[3]]はFUN(dt[1:3])等しい
frollapply(x=dt, n=3, FUN=FUN)[[4]]はFUN(dt[2:4])等しい
あれは正しいですか？ @ jerryfuyu0104

現在、最初の引数に渡される複数の列をサポートしていますが、それらを個別に処理してループします。 おそらく追加の引数multi.var=FALSEが必要になります。trueに設定すると、 xループしませんが（現在のように： list(FUN(x[[1]]),FUN(x[[2]])) ）、すべての列を渡しますFUN(x) 。

これに対する更新はありますか？

私はその前の要求を2番目にしています。

さらに、部分的なウィンドウを許可するために「部分的な」引数をサポートすることは可能でしょうか？

@eliocampは、 partialウィンドウとは何かについて詳しく説明していただけますか？

@eliocamp 「部分的な」引数をサポートすることは可能です。 adaptive=TRUE引数を使用して、この機能のサポートはすでに存在していることをご存知かもしれません。詳細については、例を参照してください。

これは、ハーフウィンドウポイントを形成するのではなく、最初から最後まで関数を計算することを意味します。
たとえば、幅が11の移動平均の場合、返される最初の要素は要素1から6の平均になります。2番目の要素は1番目から7番目の平均になり、以下同様に続きます。

@jangoreckiああ、ありがとう、私はそれを知りませんでした！ 確認してみます。

同意する、便利さだけでなくスピードのためにも、部分的な議論が必要です。 adaptive=TRUEはオーバーヘッドを追加します。
もちろん、ローリング回帰も必要なので、複数の変数を指定して、それぞれを個別にではなく、一度にローリングします。
それらのステータスに関する更新はありません。

手伝いたいのですが、私のC ++スキルはまったく存在しません。 ：sweat：完全な初心者に適していると思いますか？

C ++ではなくCでコーディングします。はい、最初から始めるのに適しています。 私はfrollmeanでまさにそれをしました。

コードを見ると、気が遠くなるようです。 しかし、私はとにかくあなたを更新します。

しかし今、さらに別の要求のために：frollmean（.SD）は名前を保持する必要があります。 より一般的には、入力が名前付きのリストのようなものである場合、froll *は名前を保持する必要があります。

data.tableを頻繁に使用する私は、現在パッケージtsibble提供されているような、「時間認識」機能があると非常に便利だと思います。 残念ながら、このパッケージはdplyr中心に開発されています。 data.tableの実装が可能かどうか疑問に思います。 この号で提案されているウィンドウ関数は、これらの機能のサブセットです。

@ywhcuhkフィードバックをありがとう、私は実際にこの問題がすでにあまりにも多くを求めていると思っていました。 そのほとんどは、非常に高速な軽量のパッケージロールで十分にカバーされています。 その他の機能については、興味のある機能ごとに新しい問題を作成することをお勧めしますので、実装/保守するかどうかの議論は、それぞれ個別に決定できます。 tstibbleのreadmeを見ただけでは、新しいものは何も見つかりません...
タイトルは「TidyTemporalData Frames」ですが、一時的な結合を提供しているようには見えません。

返信ありがとうございますtssetとxtsetに基づく操作です。data.tableの「インデックス」を拡張できると思います。どういうわけかそのような操作を可能にするために。

もちろん、これらの操作は、 shiftやbyなどのdata.table関数で実行できます。 data.tableのindexには、調査する可能性がたくさんあると思いました。 私はこれが別の問題に属するべきであることに同意します。 しかし、私は上記の議論を失うことなくそれを動かす方法を知りません...