Pandas: ステップサイズのローリングウィンドウ

'標準'関数を使用している場合、これらはベクトル化されているため、v高速（ ts.rolling(5).max().dropna()[::2] ）です。

IIUCでの節約は、関数をほんのわずかな時間（たとえば、n番目ごとの値）で適用することによってもたらされます。 しかし、それが実際的な違いを生む場合はありますか？

これは可能ですが、これが重要なユースケースを見たいと思います。 これにより、「入力と同じサイズを返す」APIも破損します。 これを実際に実装するのは難しいとは思いませんが（実装には多くの変更が必要になりますが）。 マージナルウィンドウを使用します（IOW、ウィンドウを計算し、進むにつれて、離れるポイントをドロップオフし、獲得するポイントを追加します）。 したがって、それでもすべてを計算する必要がありますが、出力はしません。

返信ありがとうございます！

IIUCでの節約は、関数をほんのわずかな時間（たとえば、n番目ごとの値）で適用することによってもたらされます。 しかし、それが実際的な違いを生む場合はありますか？

私のユースケースは、いくつかの大きな時系列データフレーム（400列、5〜25Hzでのデータ時間）で集計関数（最大値だけでなく）を実行することです。 私も過去に20kHzまでのデータで同様のこと（センサーデータの特徴工学）を行いました。 5秒のステップで30秒のウィンドウを実行すると、処理の大きなチャンクが節約されます。たとえば、5秒のステップで25Hzの場合、作業の1/125であり、1分または2時間で実行する場合の違いが生じます。

私は明らかにnumpyにフォールバックできますが、これを行うためのより高いレベルのAPIがあればいいのですが。 他の人もそれが役立つと思う場合に備えて、提案する価値があると思っただけです-私のためだけに機能を構築することは期待していません！

最初に高い周波数間隔に再サンプリングしてからローリングを試すことができます

何かのようなもの

df = df.resample（ '30s'）
df.rolling（..）。max（）（または任意の関数）

ねえ@jreback 、提案をありがとう。

これは、データmaxを実行している場合に機能します（リサンプルにはリダクション関数が必要です。そうでない場合、デフォルトでmeanになりますよね？）：

df.resample('1s').max().rolling(30).max()

ただし、30秒のデータに対してリダクション関数を実行し、次に1秒進み、次の30秒のデータに対して実行したいなどです。上記の方法では、1秒のデータに対して関数を適用し、次に別のデータに対して関数を適用します。最初の関数の30の結果で関数。

簡単な例を次に示します。ピークツーピーク計算を実行しても、2回実行しても機能しません（明らかに）。

# 10 minutes of data at 5Hz
n = 5 * 60 * 10
rng = pandas.date_range('1/1/2017', periods=n, freq='200ms')
np.random.seed(0)
d = np.cumsum(np.random.randn(n), axis=0)
s = pandas.Series(d, index=rng)

# Peak to peak
def p2p(d):
    return d.max() - d.min()

def p2p_arr(d):
    return d.max(axis=1) - d.min(axis=1)

def rolling_with_step(s, window, step, func):
    # See https://ga7g08.github.io/2015/01/30/Applying-python-functions-in-moving-windows/
    vert_idx_list = np.arange(0, s.size - window, step)
    hori_idx_list = np.arange(window)
    A, B = np.meshgrid(hori_idx_list, vert_idx_list)
    idx_array = A + B
    x_array = s.values[idx_array]
    idx = s.index[vert_idx_list + int(window/2.)]
    d = func(x_array)
    return pandas.Series(d, index=idx)

# Plot data
ax = s.plot(figsize=(12, 8), legend=True, label='Data')

# Plot resample then rolling (obviously does not work)
s.resample('1s').apply(p2p).rolling(window=30, center=True).apply(p2p).plot(ax=ax, label='1s p2p, roll 30 p2p', legend=True)

# Plot rolling window with step
rolling_with_step(s, window=30 * 5, step=5, func=p2p_arr).plot(ax=ax, label='Roll 30, step 1s', legend=True)

@alexloudenあなたの元の説明から私は次のようなものだと思います

df.resample('5s').max().rolling('30s').mean() （または任意の削減）は、あなたが望むものとより一致しています

IOW、5 sビンにあるものをすべて取り、それを1つのポイントに減らしてから、それらのビンをロールオーバーします。 この一般的な考え方は、短いタイムスケールで要約できるデータがたくさんあるということですが、実際には、これをより高いレベルでローリングする必要があります。

ねえ@jreback 、私は実際に5秒ごとに30秒以上のデータで関数を実行したいと思っています。 前の例のrolling_with_step関数を参照してください。 max / meanの追加の手順は、私のユースケースでは機能しません。

@jreback 、この議論ではまだ出されていないステップ関数が本当に必要です。 @alexloudenが説明したすべてのことを次に説明しますが、さらにユースケースを追加したいと思います。

約3〜10ミリ秒でサンプリングされた入力データを使用して時系列分析を行っているとします。 周波数領域の機能に関心があります。 それらを構築する最初のステップは、ナイキスト周波数を見つけることです。 ドメイン知識によって、それが10 Hz（100ミリ秒に1回）であることがわかっているとします。 つまり、フィーチャが入力信号を適切にキャプチャする必要がある場合は、データの周波数が少なくとも20 Hz（50ミリ秒に1回）である必要があります。 それより低い周波数にリサンプリングすることはできません。 最終的に、ここで私たちが行う計算は次のとおりです。

df.resample('50ms').mean().rolling(window=32).aggregate(power_spectrum_coeff)

ここでは、8の倍数のウィンドウサイズを選択しました。32を選択すると、ウィンドウサイズは1.6秒になります。 集計関数は、片側の周波数領域係数を返し、最初の平均成分は含まれません（fft関数は対称であり、0番目の要素に平均値があります）。 以下は、サンプルの集計関数です。

def power_spectrum_coeff():
    def power_spectrum_coeff_(x):
        return np.fft.fft(x)[1 : int(len(x) / 2 + 1)]

    power_spectrum_coeff_.__name__ = 'power_spectrum_coeff'
    return power_spectrum_coeff_

ここで、たとえば0.4秒ごとまたは0.8秒ごとのスライディングウィンドウでこれを繰り返します。 代わりに、計算を無駄にして50ミリ秒ごとにFFTを計算し、後でスライスしても意味がありません。 さらに、400ミリ秒はナイキスト周波数よりもはるかに低い2.5Hzであるため、400ミリ秒までリサンプリングすることはできません。そうすると、すべての情報が機能から失われます。

これは周波数領域の機能であり、多くの時系列関連の科学実験に適用されます。 ただし、標準偏差などのより単純な時間領域集計関数でさえ、リサンプリングでは効果的にサポートできません。

これを実際に実装するのは難しいとは思いませんが（実装には多くの変更が必要になりますが）。 マージナルウィンドウを使用します（IOW、ウィンドウを計算し、進むにつれて、離れるポイントをドロップして、獲得するポイントを追加します）。 したがって、それでもすべてを計算する必要がありますが、出力はしません。

'step'パラメーターを持ち、それを使用して実際の計算を減らすことができることは、Pandasの将来の目標でなければなりません。 stepパラメーターが返すポイントが少ない場合は、出力をスライスできるため、実行する価値はありません。 おそらくこれを行うための作業を考えると、これらのニーズを持つすべてのプロジェクトでNumpyを使用することをお勧めします。

@Murmuriaこれを行うためのプルリクエストを送信することを歓迎します。 実際にはそれほど難しくはありません。

ため、私は2番目の要求間にstepでパラメータrolling() 、私は所望の結果を得ることが可能であることを指摘したいと思いますbaseのパラメータresample() 、ステップサイズがウィンドウサイズの整数分数の場合。 @alexloudenの例を使用すると：

pandas.concat([
    s.resample('30s', label='left', loffset=pandas.Timedelta(15, unit='s'), base=i).agg(p2p) 
    for i in range(30)
]).sort_index().plot(ax=ax, label='Solution with resample()', legend=True, style='k:')

同じ結果が得られます（線が両側で30秒伸びていることに注意してください）。

集計のタイプによっては、これはまだいくらか無駄です。 @alexloudenの例のようなピークツーピーク計算の特定のケースでは、 p2p_arr()は、級数を2次元行列に再配置してから、 max()への単一の呼び出しを使用するため、ほぼ200倍高速です。 max()およびmin() 。

ローリングのstepパラメーターを使用すると、日時インデックスなしでこの機能を使用することもできます。 すでに取り組んでいる人はいますか？

上記の@alexloudenはこれを言った：

私は明らかにnumpyにフォールバックできますが、これを行うためのより高いレベルのAPIがあればいいのですが。

@alexloudenまたは知っている他の誰かがnumpyでこれを行う方法についていくつかの洞察を共有できますか？ これまでの私の調査から、これをnumpyでも行うのは簡単ではないようです。 実際、ここには未解決の問題がありますhttps://github.com/numpy/numpy/issues/7753

ありがとう

こんにちは@ tsando-上記で使用した関数rolling_with_stepは機能しませんでしたか？

@alexloudenありがとう、その関数をチェックしたところ、まだパンダに依存しているようです（入力としてシリーズを受け取り、シリーズインデックスも使用します）。 これには純粋に厄介なアプローチがあるのだろうかと思っていました。 https://github.com/numpy/numpy/issues/7753で言及したスレッドでは、numpyストライドを使用する関数を提案していますが、理解してウィンドウやステップの入力に変換するのは困難です。

@tsandoこれは私が上にリンクしたブログ投稿のPDFです-作者がGithubユーザー名を変更し、サイトを再び立ち上げていないようです。 （PDFに変換するためにローカルで実行しただけです）。

上記の私の関数は、彼の最後の例をPandasで動​​作するように変換することでした-numpyを直接使用したい場合は、次のようにすることができます： https ：

お役に立てれば！

@alexloudenありがとう！ 形状(13, 1313)配列で試してみましたが、次のエラーが発生しました。

「これは可能ですが、これが重要なユースケースを見たいと思います。」

パンダを使用して取り組んだプロジェクトが何であれ、ほとんどの場合、この機能を見逃していました。たまに適用を計算する必要があるが、各ウィンドウ内で適切な解像度が必要な場合はいつでも役立ちます。

私もこの機能に同意し、サポートします

時系列を処理するときにほぼ毎回必要になるこの機能は、視覚化と分析の両方の時系列機能を生成するためのより優れた制御を提供する可能性があります。 このアイデアを強く支持してください！

この機能にも同意してサポートする

これは、良好なウィンドウ解像度を維持しながら計算時間を短縮するのに非常に役立ちます。

特定のターゲットに合わせてさらに調整できるソリューションコードを提供します。

def average_smoothing(signal, kernel_size, stride):
    sample = []
    start = 0
    end = kernel_size
    while end <= len(signal):
        start = start + stride
        end = end + stride
        sample.append(np.mean(signal[start:end]))
    return np.array(sample)

私はこの機能に同意し、サポートします。 現在、ストップモーションになっているようです。

TBのデータがある場合、計算してからダウンサンプリングすることはできません。

それは私がすることにも非常に役立ちます。 ローカルの状態を理解するために、重複しないウィンドウのさまざまな統計が必要なTBのデータがあります。 私の現在の「修正」は、データフレームをスライスしての統計を生成するジェネレーターを作成することです。 この機能があると非常に役立ちます。

この機能は、時系列が関係する場合に必ず必要です。

同意します。確かにこの機能を追加する必要があります。株価間でウィンドウ相関を実行しようとすると、独自の関数を作成する必要があります。

そのような基本的な機能がまだないなんて信じられません！
この問題はいつ解決されますか？
ありがとう

「さらなる議論」に貢献するには：
私の使用例は、1秒の解像度で1か月のデータについて1時間あたり1つの最小/最大/中央値を計算することです。 これはエネルギー使用量のデータであり、リサンプリングで失われる1〜2秒間のピークがあります。 それ以外は、たとえば5秒/ 1分にリサンプリングしても、必要な1日あたり24ウィンドウを計算できるだけでなく、破棄する必要がある1日あたり4k / 1kウィンドウを計算する必要があるという事実は変わりません。 。

groupby asoを使用してこれを回避することは可能ですが、直感的でも、ローリング実装ほど高速でもないようです（ソート付きの2.5mil時間のウィンドウの場合は2秒）。 それは驚くほど速くて便利ですが、その力を十分に活用するには、本当に大きな議論が必要です。

私はその問題を調べた。 これは比較的簡単ですが、コードの実装方法は、ざっと見ただけで、すべてのローリングルーチンを手動で編集する必要があると思います。 それらのどれも、インデクサークラスによって与えられたウィンドウ境界を尊重しません。 もしそうなら、このリクエストと＃11704の両方を非常に簡単に解決できます。 いずれにせよ、物事を整えるのに時間をかけたい人にとっては扱いやすいと思います。 私は、問題にどのように取り組むかを示すために、中途半端なPR（MVPのためだけに、拒否されると予想されます）を開始しました。

ランニング：

import numpy as np
import pandas as pd

data = pd.Series(
    np.arange(100),
    index=pd.date_range('2020/05/12 12:00:00', '2020/05/12 12:00:10', periods=100))

print('1s rolling window every 2s')
print(data.rolling('1s', step='2s').apply(np.mean))

data.sort_index(ascending=False, inplace=True)

print('1s rolling window every 500ms (and reversed)')
print(data.rolling('1s', step='500ms').apply(np.mean))

収量

1s rolling window every 2s
2020-05-12 12:00:00.000000000     4.5
2020-05-12 12:00:02.020202020    24.5
2020-05-12 12:00:04.040404040    44.5
2020-05-12 12:00:06.060606060    64.5
2020-05-12 12:00:08.080808080    84.5
dtype: float64
1s rolling window every 500ms (and reversed)
2020-05-12 12:00:10.000000000    94.5
2020-05-12 12:00:09.494949494    89.5
2020-05-12 12:00:08.989898989    84.5
2020-05-12 12:00:08.484848484    79.5
2020-05-12 12:00:07.979797979    74.5
2020-05-12 12:00:07.474747474    69.5
2020-05-12 12:00:06.969696969    64.5
2020-05-12 12:00:06.464646464    59.5
2020-05-12 12:00:05.959595959    54.5
2020-05-12 12:00:05.454545454    49.5
2020-05-12 12:00:04.949494949    44.5
2020-05-12 12:00:04.444444444    39.5
2020-05-12 12:00:03.939393939    34.5
2020-05-12 12:00:03.434343434    29.5
2020-05-12 12:00:02.929292929    24.5
2020-05-12 12:00:02.424242424    19.5
2020-05-12 12:00:01.919191919    14.5
2020-05-12 12:00:01.414141414     9.5
2020-05-12 12:00:00.909090909     4.5
dtype: float64

実装の詳細については、PRをご覧ください（またはここ：https：//github.com/anthonytw/pandas/tree/rolling-window-step）

仕上げにもっと時間をかけたかったのですが、残念ながら、すべてのローリング機能を作り直すといううんざりする作業に取り組む余地はありませんでした。 これに取り組みたい人には、インデクサークラスによって生成されたウィンドウ境界を適用し、rolling _ * _ fixed / variable関数を統合することをお勧めします。 開始境界と終了境界では、不均一にサンプリングされたデータで特別なことを行う関数がない限り、それらが異なる必要がある理由はわかりません（その場合、その特定の関数はニュアンスをより適切に処理できるため、おそらくフラグか何かを設定します）。

これは、 get_window_bounds()アプローチを使用するカスタムウィンドウでも機能しますか？

こんにちは、私も提案をお願いします。 これは本当に便利な機能です。

'標準'関数を使用している場合、これらはベクトル化されているため、v高速（ ts.rolling(5).max().dropna()[::2] ）です。

IIUCでの節約は、関数をほんのわずかな時間（たとえば、n番目ごとの値）で適用することによってもたらされます。 しかし、それが実際的な違いを生む場合はありますか？

私はここにちょうどそのような例があります： https ：

N番目ごとは365番目ごとになります。 ウィンドウサイズはプログラムの存続期間にわたって可変であり、ステップがウィンドウサイズの整数分数であるとは限りません。

基本的に、「見ている年の日数」で段階的に設定されたウィンドウサイズが必要です。これは、これまでにこの問題で見つけたすべてのソリューションでは不可能です。

私はまた、次の文脈で同様のニーズを持っています（実際の専門的なニーズから適応）：

• タイムスタンプ列と不規則なイベントを表す値列を持つ時系列のデータフレームがあります。 犬が私の窓の下を通過したときのタイムスタンプや、犬が通過するのに何秒かかったかのように。 特定の日に6つのイベントを開催し、次の2日間はイベントをまったく開催できません。
• 30日ごとにローリングする365日のローリングウィンドウを使用して、メトリック（たとえば、私のウィンドウの前で犬が費やした平均時間）を計算したいと思います。

私が理解している限り、dataframe.rolling（）APIを使用すると、365日の期間を指定できますが、30日間の値（一定ではない行数）をスキップして次の平均を計算する必要はありません。 365日の値の選択。

明らかに、私が期待する結果のデータフレームは、最初の「犬のイベント」データフレームよりも（はるかに）少ない行数になります。

簡単な例を使用して、このリクエストについてより明確にするためです。

このシリーズがある場合：

In [1]: s = pd.Series(range(5))

In [2]: s
Out[2]:
0    0
1    1
2    2
3    3
4    4
dtype: int64

ウィンドウサイズは2 、ステップサイズは1です。 インデックス0この最初のウィンドウが評価され、インデックス1のウィンドウをステップオーバーし、インデックス2のウィンドウを評価しますか？

In [3]: s.rolling(2, step=1, min_periods=0).max()

Out[3]:
0    0.0
1    NaN # step over this observation
2    2.0
3    NaN # step over this observation
4    4.0
dtype: float64

同様に、この時間ベースのシリーズがある場合

In [1]: s = pd.Series(range(5), index=pd.DatetimeIndex(['2020-01-01', '2020-01-02', '2020-01-03', '2020-01-06', '2020-01-09']))

In [2]: s
Out[2]:
2020-01-01    0
2020-01-02    1
2020-01-03    2
2020-01-06    3
2020-01-09    4
dtype: int64

ウィンドウサイズは'3D' 、ステップサイズは'3D'です。 これは正しい結果でしょうか？

In [3]: s.rolling('3D', step='3D', min_periods=0).max()

Out[3]:
2020-01-01    0.0       # evaluate this window
2020-01-02    NaN    # step over this observation (2020-01-01 + 3 days > 2020-01-02)
2020-01-03    NaN    # step over this observation (2020-01-01 + 3 days > 2020-01-03)
2020-01-06    3.0      # evaluate this window ("snap back" to this observation)
2020-01-09    4.0      # evaluate this window (2020-01-06 + 3 days = 2020-01-09)
dtype: float64

@mroeschke wrt最初の例（[3]）では、結果は私が期待するものではありません。 これはトレーリングウィンドウであると想定します（たとえば、index = 0では、-1と0での要素の最大値になるため、max（[0]）だけです。次に、「1」インデックスをindex = 0に進めます。 + step = 1であり、次の計算はmax（[0,1]）、次にmax（[1,2]）などになります。意図したように見えるのはステップサイズが2なので、次のようになります。 index = 0からindex = 0 + 2 = 2に移動し（インデックス1をスキップ）、そのように続行します。この場合はほぼ正しいですが、NaNは存在しないはずです。ただし、このサイズは「2倍」しかない場合があります。たとえば、患者の500Hz ECGデータは約1時間に相当し、180万サンプルです。2分ごとに5分間の移動平均が必要な場合は、次のようになります。 30の有効な計算と180万のNaNをわずかに下回る180万の要素:-)

インデックス付けの場合、ステップサイズ= 1が現在の動作です。つまり、ウィンドウ内のデータを使用して対象の特徴を計算し、ウィンドウを1つシフトしてから、繰り返します。 この例では、ウィンドウ内のデータを使用して対象の特徴を計算し、60,000インデックスずつシフトしてから、繰り返します。

当時の同様の発言。 この場合、このタイプのウィンドウを実装する正しい方法に関して意見の相違があるかもしれませんが、私の意見では、「最良の」（TM）方法は、時間t0から開始し、範囲内のすべての要素を見つけることです（t0-window 、t0]、特徴を計算してから、ステップサイズで移動します。要素の最小数より少ないウィンドウをすべて破棄します（構成可能、デフォルトは1）。この例は末尾のウィンドウ用ですが、変更できます。これには大きなギャップで時間を浪費するという欠点がありますが、ギャップはインテリジェントに処理でき、単純な方法で計算しても（私のように怠惰なので）、この問題は実際にはまだ見ていません。 、ギャップは通常、実際のデータで問題になるほど大きくないため。YMMV。

多分それはより明確ですか？ 上記の私の例とコードを見てください。それはそれをよりよく説明するかもしれません。

明確化@anthonytwをありがとう。 確かに、 stepを「ステップツーポイント」として解釈する必要があったようです。

NaNについては、出力結果にNaNを自動的にドロップするという感情は理解していますが、 https： //github.com/pandas-dev/pandas/issues/15354#issuecomment -278676420 by @jrebackに記載されているように、出力が入力と同じ長さになるようにするためのAPI整合性の考慮事項。 NaNも保持したいユーザーがいる可能性があり（多分？）、 rolling(..., step=...).func()操作後もdropnaは引き続き使用できます。

@mroeschke例外を設ける必要があると思います。 ドキュメントに明示的なメモを入れ、動作がデフォルトでない限り、ジャンクでいっぱいのベクトルを返さないことによって悪影響を受けることはありません。 NaNを維持すると、目的の半分が無効になります。 1つの目的は、コストのかかる計算を実行する回数を制限することです。 もう1つの目的は、機能セットを管理しやすいものに最小化することです。 私があなたに与えたその例は実際のものであり、患者監視アプリケーションで実際に処理しなければならないほど多くのデータではありません。 本当に必要なスペースの60000倍を割り当ててから、配列を検索してNaNを削除する必要がありますか？ 計算したい機能ごとに？

1回の計算で値の配列が生成される場合があることに注意してください。 ECG波形で何をしたいですか？ もちろん、パワースペクトルを計算してください！ したがって、1つの完全なPSDベクトル（150,000要素）に180万回（2TBのデータ）の十分なスペースを割り当ててから、フィルターをかけて気になる部分（34MB）を取得する必要があります。 すべてのシリーズ。 すべての患者のために。 もっとRAMを購入する必要があると思います！

NaNは、一部の機能では、意味のある出力になる可能性があることにも言及する価値があります。 その場合、意味のあるNaNとデータをパディングするジャンクNaNの違いがわかりません。

APIを維持したいという願望は理解していますが、これは既存のコードを壊す機能ではありません（以前は存在しなかった新しい機能であるため）。機能を考えると、誰もがそれを生成すると期待する理由はありません。同じサイズの出力。 そして、たとえそうだったとしても、ステップサイズについてのドキュメントのメモで十分でしょう。 不利な点は、「一貫性のある」APIを持つことの利点をはるかに上回ります（以前は存在しなかった機能については、気を付けてください）。 この方法で進めないと機能が損なわれます。その場合、実装する価値すらありません（私の経験では、ほとんどの場合、スペースコストが大きな要因です）。