{"article":{"slug":"two-stack-sliding-window-aggregation","title":"Two-Stack Sliding-Window Aggregation","subtitle":null,"summary":"An aggregation is some kind of summary of a set of data. This can be the sum, length, minimum, etc. It is quite common to want to calculate such a summary repeatedly, e.g. “the maximum noise level in dB for the past 30 seconds” for a nuisance detector. In such a case we say there is a sliding window over our data, and we want to aggregate over our window.","content_type":"research","language":"en","canonical_url":"https://orlp.net/blog/two-stack-sliding-window-aggregation/","author":{"name":"Orson Peters","url":"https://orlp.net/","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"orlp.net","url":"https://orlp.net/","listing_slug":null,"listing":null},"topics":[{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Algorithms","slug":"algorithms","url":"https://listedarticles.com/topics/algorithms"},{"name":"Computer Science","slug":"computer-science","url":"https://listedarticles.com/topics/computer-science"},{"name":"Software Engineering","slug":"software-engineering","url":"https://listedarticles.com/topics/software-engineering"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1195,"reading_minutes":5,"published_at":"2026-10-03T00:00:00.000Z","added_at":"2026-10-03T15:10:31.225Z","updated_at":"2026-10-03T15:10:31.225Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":false},"profile_url":"https://listedarticles.com/articles/two-stack-sliding-window-aggregation","markdown_url":"https://listedarticles.com/articles/two-stack-sliding-window-aggregation.md","example":false,"citation":"Orson Peters, orlp.net. \"Two-Stack Sliding-Window Aggregation.\" 3 Oct 2026. https://orlp.net/blog/two-stack-sliding-window-aggregation/ (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://orlp.net/blog/two-stack-sliding-window-aggregation/"},"body_markdown":"# Two-Stack Sliding-Window Aggregation\n\nAn aggregation is some kind of summary of a set of data. This can be the sum, length, minimum, etc. It is quite common to want to calculate such a summary repeatedly, e.g. “the maximum noise level in dB for the past 30 seconds” for a nuisance detector. In such a case we say there is a sliding window over our data, and we want to aggregate over our window.\n\nIf our aggregation is a binary operator with an inverse, like integer sums, there is a very easy solution using a double-ended queue:\n\n```\n```\nfrom collections import deque\n\nclass SlidingWindowSum:\n def __init__(self):\n self.sum = 0\n self.elems = deque()\n \n def push(self, x):\n self.sum += x\n self.elems.append(x)\n \n def pop(self):\n self.sum -= self.elems.popleft()\n \n def eval(self):\n return self.sum\n```\n```\n\nBut what if our operator has no inverse? This is actually the case for most interesting summaries\nsuch as minimum, quantile, approximate unique count (for example using HyperLogLog), etc. In fact, even something as simple as a floating-point sum suffers from the fact\nthat floating-point addition is not invertible. For example, if you ever have a\n\n```\nNaN\n```\n\nin your input\ndata with the above naive algorithm your sum will forever remain\n\n```\nNaN\n```\n\n, even long after the bad value\nhas left your window.\n\nSix years ago I came up with an algorithm for maintaining just the minimum/maximum in a sliding window and posted it to cs.stackexchange. I now consider this algorithm pointless, because it turns out there is a simple and efficient algorithm that solves this problem for a very wide class of aggregations. I’m writing this blog post to spread the word, because I feel it should be more widely known.\n\n## Folklore\n\nI came across this algorithm while reading a far more advanced paper, Low-Latency Sliding-Window Aggregation in Worst-Case Constant Time by Tangwongsan et al. Why is this paper titled low-latency? Because it does the same as what I’m about to describe, but in O(1) time for each step. However, in it they also described a “two-stack” algorithm, which does it in amortized O(1), and is far, far simpler.\n\nFunnily enough that paper attributes this algorithm to “adamax” from a 2011 Stack Overflow post. They in turn credit a 2001 lecture note by D. Sleator for the inspiration. However, this lecture note does not describe a sliding window aggregate, it describes the classical two-stack algorithm for implementing a FIFO queue and does amortized analysis on it. Ultimately I would not be surprised to find that this algorithm was already described in an obscure paper from the 1970s, seeing how simple and brilliant it is.\n\n## Two stacks\n\nLike the authors of the paper, I will generalize the two-stack algorithm to arbitrary associative\naggregation functions. By abstracting the aggregation as a set of functions,\n\n```\nempty()\n```\n\n,\n\n```\nunit(x)\n```\n\n,\n\n```\ncombine(x, y)\n```\n\nand\n\n```\nfinalize(x)\n```\n\n, you can describe many possible aggregations, for example a mean:\n\n```\n```\nempty = lambda: (0, 0)\nunit = lambda x: (x, 1)\ncombine = lambda x, y: (x[0] + y[0], x[1] + y[1])\nfinalize = lambda x: x[0] / x[1] if x[1] else None\n```\n```\n\nI’d like to note here that these functions have the following signatures:\n\n```\n```\nfn empty() -> Agg;\nfn unit(x: Value) -> Agg;\nfn combine(x: Agg, y: Agg) -> Agg;\nfn finalize(x: Agg) -> Out;\n```\n```\n\nI’m making a distinction here between\n\n```\nValue\n```\n\n,\n\n```\nAgg\n```\n\nand\n\n```\nOut\n```\n\nbecause while they seem superficially\nsimilar for something like an integer sum, for an approximate unique count on strings you would have\n\n```\n(Value, Agg, Out) = (String, HyperLogLogSketch, u64)\n```\n\n, three wildly different types.\n\nWithout further ado, the algorithm:\n\n```\n```\nclass TwoStackAgg:\n def __init__(self):\n self.values = []\n self.values_agg = empty()\n self.cum_aggs = []\n \n def push(self, x):\n self.values.append(x)\n self.values_agg = combine(self.values_agg, unit(x))\n \n def pop(self):\n if not self.cum_aggs:\n cum_agg = empty()\n while self.values:\n cum_agg = combine(unit(self.values.pop()), cum_agg)\n self.cum_aggs.append(cum_agg)\n self.values_agg = empty()\n self.cum_aggs.pop()\n \n def eval(self):\n return finalize(\n combine(self.cum_aggs[-1], self.values_agg)\n if self.cum_aggs else self.values_agg\n )\n```\n```\n\nThat’s it, the entire algorithm. There’s two stacks (\n\n```\nvalues\n```\n\nand\n\n```\ncum_aggs\n```\n\n)\nand one more aggregate,\n\n```\nvalues_agg\n```\n\n. At any point in time\n\n```\nvalues_agg\n```\n\nholds the aggregate of\n\n```\nvalues\n```\n\n, and\n\n```\ncum_aggs\n```\n\ncontains the cumulative\naggregates of all values in our window that aren’t in\n\n```\nvalues\n```\n\n, in reverse\norder. From this we can get the aggregate over our entire window in constant\ntime by by combining the last value of\n\n```\ncum_aggs\n```\n\nwith\n\n```\nvalues_agg\n```\n\n.\n\nThe neat part is that (assuming\n\n```\nw\n```\n\nis our window size) every\n\n```\nw\n```\n\nth operation\nwe drain all of\n\n```\nvalues\n```\n\nand maintain a running aggregate while pushing the\npartial cumulative aggregates onto\n\n```\ncum_aggs\n```\n\n. This is what makes it amortized\nO(1), doing\n\n```\nO(w)\n```\n\ninternal operations every\n\n```\nw\n```\n\nth pop bounds the total amount\nof work per element to\n\n```\nO(1)\n```\n\n, even though a singular operation might not be\nconstant time.\n\nI think this is best visualized. Suppose we sum\n\n```\n[1, 2, ..., 10]\n```\n\nwith a\nfixed-size sliding window of four elements, then the state on each\n\n```\neval()\n```\n\ncall\nwould look like this (\n\n```\nvalues_agg\n```\n\nnot shown as it is simply the aggregate of\nthe values):\n\n```\n```\n cum_aggs values out\n [] [] = 0\n [] [1] = 1\n [] [1, 2] = 1 + 2\n [] [1, 2, 3] = 1 + 2 + 3\n [] [1, 2, 3, 4] = 1 + 2 + 3 + 4\n[4, 3 + 4, 2 + 3 + 4] [5] = 2 + 3 + 4 + 5\n [4, 3 + 4] [5, 6] = 3 + 4 + 5 + 6\n [4] [5, 6, 7] = 4 + 5 + 6 + 7\n [] [5, 6, 7, 8] = 5 + 6 + 7 + 8\n[8, 7 + 8, 6 + 7 + 8] [9] = 6 + 7 + 8 + 9\n [8, 7 + 8] [9, 10] = 7 + 8 + 9 + 10\n [8] [9, 10] = 8 + 9 + 10\n [] [9, 10] = 9 + 10\n [10] [] = 10\n [] [] = 0\n```\n```\n\nIn total the memory usage is\n\n```\nO(w)\n```\n\n, where\n\n```\nw\n```\n\nis your maximum window size.\nNote that for simplicity of analysis and the example I assumed a fixed-size\nwindow\n\n```\nw\n```\n\n, but there is nothing about the two-stack algorithm that requires\nthis. You can call\n\n```\npush(x)\n```\n\nand\n\n```\npop()\n```\n\nas many times as you’d like between\neach\n\n```\neval()\n```\n\n, growing and shrinking the window size as needed.\n\n## Floating-point non-associativity\n\nNote that we required above that our aggregate\n\n```\ncombine\n```\n\nis associative, meaning:\n\n```\n```\ncombine(combine(x, y), z) = combine(x, combine(y, z))\n```\n```\n\nTechnically speaking, floating-point addition doesn’t respect this. Nevertheless, the above algorithm is still very useful because the results closely match the expected outcome, even more so if you use a compensated summation algorithm like Kahan summation.\n\nHowever, there is a second very useful property of the above algorithm. Each aggregate\nis strictly a combination of the elements in the window, and none outside the window.\nThis means if your window contains a\n\n```\nNaN\n```\n\nor infinity (or some other outlier), that\nvalue only poisons the windows that contain it rather than the rest of your computation.\n\nBut even without\n\n```\nNaN\n```\n\nor infinity it is useful, due to not propagating errors\nendlessly. E.g. if your sliding window starts with\n\n```\n[1e20, 1]\n```\n\n, this is what would\nhappen with a naive rolling sum:\n\n```\n```\n>>> 1e20 + 1 - 1e20 - 1\n-1.0\n```\n```\n\nCompensated summation will reduce these effects, but not making your result depend on values outside of the window will eliminate long-term error accumulation entirely.","body_html":"

Two-Stack Sliding-Window Aggregation

\n

An aggregation is some kind of summary of a set of data. This can be the sum, length, minimum, etc. It is quite common to want to calculate such a summary repeatedly, e.g. “the maximum noise level in dB for the past 30 seconds” for a nuisance detector. In such a case we say there is a sliding window over our data, and we want to aggregate over our window.

\n

If our aggregation is a binary operator with an inverse, like integer sums, there is a very easy solution using a double-ended queue:

\n
\n

from collections import deque

\n

class SlidingWindowSum:\n def init(self):\n self.sum = 0\n self.elems = deque()

\n
def push(self, x):\n    self.sum += x\n    self.elems.append(x)\n\ndef pop(self):\n    self.sum -= self.elems.popleft()\n\ndef eval(self):\n    return self.sum
\n
\n

But what if our operator has no inverse? This is actually the case for most interesting summaries\nsuch as minimum, quantile, approximate unique count (for example using HyperLogLog), etc. In fact, even something as simple as a floating-point sum suffers from the fact\nthat floating-point addition is not invertible. For example, if you ever have a

\n
NaN
\n

in your input\ndata with the above naive algorithm your sum will forever remain

\n
NaN
\n

, even long after the bad value\nhas left your window.

\n

Six years ago I came up with an algorithm for maintaining just the minimum/maximum in a sliding window and posted it to cs.stackexchange. I now consider this algorithm pointless, because it turns out there is a simple and efficient algorithm that solves this problem for a very wide class of aggregations. I’m writing this blog post to spread the word, because I feel it should be more widely known.

\n

Folklore

\n

I came across this algorithm while reading a far more advanced paper, Low-Latency Sliding-Window Aggregation in Worst-Case Constant Time by Tangwongsan et al. Why is this paper titled low-latency? Because it does the same as what I’m about to describe, but in O(1) time for each step. However, in it they also described a “two-stack” algorithm, which does it in amortized O(1), and is far, far simpler.

\n

Funnily enough that paper attributes this algorithm to “adamax” from a 2011 Stack Overflow post. They in turn credit a 2001 lecture note by D. Sleator for the inspiration. However, this lecture note does not describe a sliding window aggregate, it describes the classical two-stack algorithm for implementing a FIFO queue and does amortized analysis on it. Ultimately I would not be surprised to find that this algorithm was already described in an obscure paper from the 1970s, seeing how simple and brilliant it is.

\n

Two stacks

\n

Like the authors of the paper, I will generalize the two-stack algorithm to arbitrary associative\naggregation functions. By abstracting the aggregation as a set of functions,

\n
empty()
\n

,

\n
unit(x)
\n

,

\n
combine(x, y)
\n

and

\n
finalize(x)
\n

, you can describe many possible aggregations, for example a mean:

\n
\n

empty = lambda: (0, 0)\nunit = lambda x: (x, 1)\ncombine = lambda x, y: (x[0] + y[0], x[1] + y[1])\nfinalize = lambda x: x[0] / x[1] if x[1] else None

\n
\n

I’d like to note here that these functions have the following signatures:

\n
\n

fn empty() -> Agg;\nfn unit(x: Value) -> Agg;\nfn combine(x: Agg, y: Agg) -> Agg;\nfn finalize(x: Agg) -> Out;

\n
\n

I’m making a distinction here between

\n
Value
\n

,

\n
Agg
\n

and

\n
Out
\n

because while they seem superficially\nsimilar for something like an integer sum, for an approximate unique count on strings you would have

\n
(Value, Agg, Out) = (String, HyperLogLogSketch, u64)
\n

, three wildly different types.

\n

Without further ado, the algorithm:

\n
\n

class TwoStackAgg:\n def init(self):\n self.values = []\n self.values_agg = empty()\n self.cum_aggs = []

\n
def push(self, x):\n    self.values.append(x)\n    self.values_agg = combine(self.values_agg, unit(x))\n\ndef pop(self):\n    if not self.cum_aggs:\n        cum_agg = empty()\n        while self.values:\n            cum_agg = combine(unit(self.values.pop()), cum_agg)\n            self.cum_aggs.append(cum_agg)\n        self.values_agg = empty()\n    self.cum_aggs.pop()\n\ndef eval(self):\n    return finalize(\n        combine(self.cum_aggs[-1], self.values_agg)\n        if self.cum_aggs else self.values_agg\n    )
\n
\n

That’s it, the entire algorithm. There’s two stacks (

\n
values
\n

and

\n
cum_aggs
\n

)\nand one more aggregate,

\n
values_agg
\n

. At any point in time

\n
values_agg
\n

holds the aggregate of

\n
values
\n

, and

\n
cum_aggs
\n

contains the cumulative\naggregates of all values in our window that aren’t in

\n
values
\n

, in reverse\norder. From this we can get the aggregate over our entire window in constant\ntime by by combining the last value of

\n
cum_aggs
\n

with

\n
values_agg
\n

.

\n

The neat part is that (assuming

\n
w
\n

is our window size) every

\n
w
\n

th operation\nwe drain all of

\n
values
\n

and maintain a running aggregate while pushing the\npartial cumulative aggregates onto

\n
cum_aggs
\n

. This is what makes it amortized\nO(1), doing

\n
O(w)
\n

internal operations every

\n
w
\n

th pop bounds the total amount\nof work per element to

\n
O(1)
\n

, even though a singular operation might not be\nconstant time.

\n

I think this is best visualized. Suppose we sum

\n
[1, 2, ..., 10]
\n

with a\nfixed-size sliding window of four elements, then the state on each

\n
eval()
\n

call\nwould look like this (

\n
values_agg
\n

not shown as it is simply the aggregate of\nthe values):

\n
\n
         cum_aggs values        out\n               [] []            = 0\n               [] [1]           = 1\n               [] [1, 2]        = 1 + 2\n               [] [1, 2, 3]     = 1 + 2 + 3\n               [] [1, 2, 3, 4]  = 1 + 2 + 3 + 4
\n

[4, 3 + 4, 2 + 3 + 4] [5] = 2 + 3 + 4 + 5\n [4, 3 + 4] [5, 6] = 3 + 4 + 5 + 6\n [4] [5, 6, 7] = 4 + 5 + 6 + 7\n [] [5, 6, 7, 8] = 5 + 6 + 7 + 8\n[8, 7 + 8, 6 + 7 + 8] [9] = 6 + 7 + 8 + 9\n [8, 7 + 8] [9, 10] = 7 + 8 + 9 + 10\n [8] [9, 10] = 8 + 9 + 10\n [] [9, 10] = 9 + 10\n [10] [] = 10\n [] [] = 0

\n
\n

In total the memory usage is

\n
O(w)
\n

, where

\n
w
\n

is your maximum window size.\nNote that for simplicity of analysis and the example I assumed a fixed-size\nwindow

\n
w
\n

, but there is nothing about the two-stack algorithm that requires\nthis. You can call

\n
push(x)
\n

and

\n
pop()
\n

as many times as you’d like between\neach

\n
eval()
\n

, growing and shrinking the window size as needed.

\n

Floating-point non-associativity

\n

Note that we required above that our aggregate

\n
combine
\n

is associative, meaning:

\n
\n

combine(combine(x, y), z) = combine(x, combine(y, z))

\n
\n

Technically speaking, floating-point addition doesn’t respect this. Nevertheless, the above algorithm is still very useful because the results closely match the expected outcome, even more so if you use a compensated summation algorithm like Kahan summation.

\n

However, there is a second very useful property of the above algorithm. Each aggregate\nis strictly a combination of the elements in the window, and none outside the window.\nThis means if your window contains a

\n
NaN
\n

or infinity (or some other outlier), that\nvalue only poisons the windows that contain it rather than the rest of your computation.

\n

But even without

\n
NaN
\n

or infinity it is useful, due to not propagating errors\nendlessly. E.g. if your sliding window starts with

\n
[1e20, 1]
\n

, this is what would\nhappen with a naive rolling sum:

\n
\n

1e20 + 1 - 1e20 - 1\n-1.0

\n
\n

Compensated summation will reduce these effects, but not making your result depend on values outside of the window will eliminate long-term error accumulation entirely.

","headings":[{"level":1,"text":"Two-Stack Sliding-Window Aggregation","id":"two-stack-sliding-window-aggregation"},{"level":2,"text":"Folklore","id":"folklore"},{"level":2,"text":"Two stacks","id":"two-stacks"},{"level":2,"text":"Floating-point non-associativity","id":"floating-point-non-associativity"}]}}