This blog does not introduce anything essentially new, though it may sound like it. At best, a much more different and maybe more? intuitive way to implement this. This was previously discovered (and improved, generalized, etc.) here
Hello Codeforces,
Around a year ago, the problem Boardgame Expo was set in CEOI 2025. I think the editorial mentions using a DSU adapted to have deque-like undoing. Upon trying to actually upsolve this problem earlier this year, I remembered only that "deque-like undoing" was necessary, so I tried coming up with it. I'd actually note that the problem itself doesn't require the full range of deque-like operations, as the data structures only need to pop. So, the standard queue-like implementation works here, though with maybe some additional considerations.
So, realizing I've been duped and wrote an unnecessary algorithm, I decided to maybe publish this absolutely brilliant discovery with the world. I acknowledge that it is likely it is wrong.
A bunch of useless words to pad the blog
One may wonder why queue-like doesn't work here. One may also be quick to realize that the push/pop operations that may occur on the same end of the deque are complements of each other, which, given queue-like works on amortized time complexity, means that one could repeatedly do the supposed amortized operations to result in quadratic time complexity.
In my view, though better implementations may not necessarily structure the code around this idea, the queue-like algorithm interweaves two stack-like structures with the following property:
- The stack is formed of multiple buckets
- Each bucket has a fixed capacity and it may never hold a partial amount of elements in it (i.e. they're either full or empty)
- The effective stack is represented as the read of the elements from the last bucket to the first
Queue-like then establishes a list of buckets as powers of two. It works because as you push elements on a stack elements' potential increases (up to $$$log$$$ per element, depending on index of bucket any element is from), and when, from the same stack, you start popping elements, the count of operations is limited by the total sum of potentials (you may not move an element further left than the number of buckets actually are left).

Illustration of the structure of the queue-like algorithm.
So, the actual soul of this trick is this power-of-two structured stack. I feel like once someone told me that Aho-Corasick can be adapted to admit insertions using this same stack. So, it's pretty cool.
Deque-like
So, again, the issue is that this power-of-two stack only works in an offline manner. I.e., one may first push, then pop. Whereas, in a deque, if we are to split it into two stacks and work from there, the stack needs to work in an online manner.
My idea was to just duplicate the buckets. I.e., instead of the buckets being of sizes $$$1, 2, 4, ...$$$, instead we'd have $$$1, 1, 2, 2, 4, 4,...$$$.
If in the standard power-of-two stack things are pretty clear (i.e., the occupied buckets are just the 1-bits in the writing in base-2 of the size of the stack), here things are more dynamic. Particularly, pushing works as follows:
- If both the first and second $$$1$$$-bucket is off, push the element in the second one
- If only the first $$$1$$$-bucket is off, push the element there
- Otherwise:
- Form a $$$2$$$-group by concatenating the contents of the two $$$1$$$-buckets together
- Now just push the element in the second $$$1$$$-bucket
- Push the $$$2$$$-group using a similar strategy, only applied to the further buckets. Note that this may imply pushing a $$$4$$$-group, $$$8$$$-group, etc.
The second-then-first bucket thing is just that the list of elements is still coherent when read from right to left.
Popping is much easier by contrast.
- First, identify the smallest full bucket. Again, second-then-first applies in case of equality.
- Then, just remove the last element, and redistribute the elements in the second-buckets of the lesser sizes.
I don't actually have any formal proof for the amortization of all of this. I don't currently care enough to prove it. I think the first time I tried I came up with asserting that it amortizes to $$$O(1)$$$. Which is wrong because the $$$O(log)$$$ lower-bound is sort of proven for the queue-like case. The intuition is that, once you redistribute things through pop, the amount of work required to push the elements of a second-bucket to the next level is proportional to it. It is similar for a first-bucket. Mostly because, when each of these are instantiated, the sum of sizes of empty buckets below them sort of has to be equal to them (i.e. either all second or first buckets of lower order are empty upon instantiation).
Of course, the full deque-like idea is just interweaving the buckets of the left and right stacks in order of their sizes when pushed to the commutative DS (e.g. DSU).
Here is a fun AI-slop animation of some processes happening in a single stack. Note the order of the stacks is the same as the previous illustration.

I apologise for the abysmal FPS rate.
Aand here is the code of this. Note I wrote this at like 1am, and I hate when people play codingame and codegolf.
Usage of this horrible template
I hope you liked this idea. Goodbye.




