Hello, Codeforces!↵
↵
Some time ago I invented an interesting data structure and I'd like to share it with the community. Maybe, it was known before, and if you knew about it before my blog post, please share the link to the source.↵
↵
# What can the data structure do?↵
↵
Given an array $a$ that contains $n$ elements and the operation $op$ that satisfiessome properties:↵
↵
1. Aassociative property: $(x\ op\ y) op\ z = x\ op (y\ op\ z)$.↵
2. Commutative property (optional, not required): $x\ op\ y = y\ op\ x is true for every $x$, $y$ and $z$.↵
↵
So, such operations as $gcd$, $\min$, $\max$, sum, multiplication, $and$, $or$, $xor$, etc. satisfy these conditions.↵
↵
Also we have some queries $l, r$. For each query, we need to find $a_l\ op\ a_{l+1}\ op\ \dots op\ a_r$. Let's call such queries $q(l, r)$.↵
↵
My data structure can process such queries in $O(1)$ time with $O(n \cdot \log \log n)$ preprocessing time and $O(n \cdot \log \log n)$ memory.↵
↵
# How it works?↵
↵
[cut]↵
↵
#↵
↵
## 1. Sqrt↵
↵
Let's do a sqrt-decomposition. We divide our array in $\sqrt{n}$ blocks, each block has size $\sqrt{n}$. For each block, we compute:↵
↵
1. Answers to the queries that lie in the block and begin at the beginning of the block _(prefix-op)_↵
2. Answers to the queries that lie in the block and end at the end of the block _(suffix-op)_↵
↵
And we'll calculate another one thing:↵
↵
3. `between[i, j]` $i \le j$ -- answer to the query that begins at the start of block $i$ and ends at the end of block $j$. Note that we have $\sqrt{n}$ blocks, so the size of this array will be $O(\sqrt{n}^2) = O(n)$.↵
↵
Let's see the example.↵
↵
Let $op$ be $+$ (we calculate sum on the segment) and we have the following array $a$:↵
↵
`1 2 3 4 5 6 7 8 9`↵
↵
It will be divided onto three blocks: `1 2 3`, `4 5 6` and `7 8 9`.↵
↵
For first block _prefix-op_ is `1 3 6` and _suffix-op_ is `6 5 3`.↵
↵
For second block _prefix-op_ is `4 9 15` and _suffix-op_ is `15 11 6`.↵
↵
For third block _prefix-op_ is `7 15 24` and _suffix-op_ is `24 17 9`.↵
↵
$between$ array is:↵
↵
~~~~~↵
6 21 45↵
- 15 39↵
- - 24↵
~~~~~↵
↵
It's obvious to see that these arrays can be easily calculated in $O(n)$ time and memory.↵
↵
We already can answer some queries using these arrays. If the query doesn't fit into one block, we can divide it onto three parts: suffix of a block, then some segment of contiguous blocks and then prefix of some block. We can answer a query by dividing it into three parts and taking $op$ of some value from _suffix-op_, then some value from $between$, then some value from _prefix-op_.↵
↵
But if we have queries that entirely fit into one block, we cannot process them using these three arrays. So, we need to do something.↵
↵
## 2. Tree↵
↵
We cannot answer only the queries that entirely fit in one block. But what **if we build the same structure as described above for each block?** Yes, we can do it. And we do it recursively, until we reach the block size of $1$ or $2$. Answers for such blocks can be calculated easily in $O(1)$.↵
↵
So, we get a tree. Each node of the tree represents some segment of the array. Node that represents array segment with size $k$ has $\sqrt{k}$ children -- for each block. Also each node contains the three arrays described above for the segment it contains. The root of the tree represents the entire array. Nodes with segment lengths $1$ or $2$ are leaves.↵
↵
Also it's obvious that the radius of this tree is $O(\log \log n)$, because if some vertex of the tree represents an array with length $k$, then its children have length $\sqrt{k}$. $\log(\sqrt{k}) = \frac{\log{k}}{2}$, so $\log k$ decreases two times every layer of the tree and so its height is $O(\log \log n)$. The time for building and memory usage will be $O(n \cdot \log \log n)$, because every element of the array appears exactly once on each layer of the tree.↵
↵
Now we can answer the queries in $O(\log \log n)$. We can go down on the tree until we meet a segment with length $1$ or $2$ (answer for it can be calculated in $O(1)$ time) or meet the first segment in which our query doesn't fit entirely into one block. See the first section on how to answer the query in this case.↵
↵
OK, now we can do $O(\log \log n)$ per query. Can it be done faster?↵
↵
## 3. Optimizing the query complexity↵
↵
One of the most obvious optimization is to binary search the tree node we need. Using binary search, we can reach the $O(\log \log \log n)$ complexity per query. Can we do it even faster?↵
↵
The answer is yes. Let's assume the following two things:↵
↵
1. Each block size is a power of two.↵
2. All the blocks are equal on each layer.↵
↵
To reach this, we can add some zero elements to our array so that its size becomes a power of two.↵
↵
When we use this, some block sizes may become twice larger to be a power of two, but it still be $O(\sqrt{k})$ in size and we keep linear complexity for building the arrays in a segment.↵
↵
Now, we can easily check if the query fits entirely into a block with size $2^k$. Let's write the ranges of the query, $l$ and $r$ (we use 0-indexation) in binary form. For instance, let's assume $k=4, l=39, r=46$. The binary representation of $l$ and $r$ is:↵
↵
`l = 39(10) = 100111(2)`↵
↵
`r = 46(10) = 101110(2)`↵
↵
Remember that one layer contains segments of the equal size, and the block on one layer have also equal size (in our case, their size is $2^k = 2^4 = 16$. The blocks cover the array entirely, so the first block covers elements $(0 - 15)$ (`000000 - 001111` in binary), the second one covers elements $(16-31)$ (`010000 - 011111` in binary) and so on. We see that the indices of the positions covered by one block may differ only in $k$ (in our case, $4$) last bits. In our case $l$ and $r$ have equal bits except four lowest, so they lie in one block.↵
↵
So, we need to check if nothing more that $k$ smallest bits differ (or $l\ xor\ r$ doesn't exceed $2^k-1$).↵
↵
Using this observation, we can find a layer that is suitable to answer the query quickly. How to do this:↵
↵
1. For each $i$ that doesn't exceed the array size, we find the highest bit that is equal to $1$. To do this quickly, we use DP and a precalculated array.↵
↵
2. Now, for each $q(l, r)$ we find the highest bit of $l\ xor\ r$ and, using this information, it's easy to choose the layer on which we can process the query easily. We can also use a precalculated array here.↵
↵
For more details, see the code below.↵
↵
So, using this, we can answer the queries in $O(1)$ each. Hooray! :)↵
↵
# Conclusion↵
↵
We have a data structure that asymptotically answers the queries on a segment very fast. But, the constant of this data structures is big enough. Also it doesn't support changing the elements. But it can be modified to perform modification queries in something about $O(\sqrt{n})$ for modifying a single element. But in this case, query complexity becomes $O(\log \log n)$. You can think how to do this as an exercise.↵
↵
# Problems↵
↵
[https://www.codechef.com/NOV17/problems/SEGPROD](https://www.codechef.com/NOV17/problems/SEGPROD)↵
↵
# Code↵
↵
[Here it is](https://paste.ubuntu.com/2636738772378/)↵
↵
If you have some suggestions on how to improve this data structure or how to modify it, or something is written unclear and needs more explanation, feel free to write in the comments.↵
↵
**UPD**: As it's noticed in the [comment](#comment-406976), this algorithm (and some more optimal ones) can be found in [this article](https://pdfs.semanticscholar.org/cf74/0240d3a7440e23e92a09bf590cb70544cf4f.pdf) (thanks [user:Rafbill,2018-01-12]).↵
↵
**UPD2**: As [user:geniucos,2018-01-12] described in the [comment](#comment-407003), we can improve the time complexity to $O(n\log^* n)$ for preprocessing if $x\ op\ x$ applies. Let the block size is $O(\log n)$, not $O(\sqrt{n})$. We use a sparse table instead of $between$ array. We will have $O(\frac{n}{\log n})$ blocks and time complexity for building a sparse table will still be $O(\frac{n}{\log n}\cdot \log \frac{n}{\log n}) \approx O(\frac{n}{\log n}\cdot \log n) = O(n)$. The tree will have much smaller layers and we still have $O(1)$ per query. ↵
↵
**UPD3**: The code is adjusted to work with non-commutative operations. The commutative property removed from the post.
↵
Some time ago I invented an interesting data structure and I'd like to share it with the community. Maybe, it was known before, and if you knew about it before my blog post, please share the link to the source.↵
↵
# What can the data structure do?↵
↵
Given an array $a$ that contains $n$ elements and the operation $op$ that satisfies
↵
1. A
2. Commutative property (optional, not required): $x\ op\ y = y\ op\ x
↵
So, such operations as $gcd$, $\min$, $\max$, sum, multiplication, $and$, $or$, $xor$, etc. satisfy these conditions.↵
↵
Also we have some queries $l, r$. For each query, we need to find $a_l\ op\ a_{l+1}\ op\ \dots op\ a_r$. Let's call such queries $q(l, r)$.↵
↵
My data structure can process such queries in $O(1)$ time with $O(n \cdot \log \log n)$ preprocessing time and $O(n \cdot \log \log n)$ memory.↵
↵
# How it works?↵
↵
[cut]↵
↵
#↵
↵
## 1. Sqrt↵
↵
Let's do a sqrt-decomposition. We divide our array in $\sqrt{n}$ blocks, each block has size $\sqrt{n}$. For each block, we compute:↵
↵
1. Answers to the queries that lie in the block and begin at the beginning of the block _(prefix-op)_↵
2. Answers to the queries that lie in the block and end at the end of the block _(suffix-op)_↵
↵
And we'll calculate another one thing:↵
↵
3. `between[i, j]` $i \le j$ -- answer to the query that begins at the start of block $i$ and ends at the end of block $j$. Note that we have $\sqrt{n}$ blocks, so the size of this array will be $O(\sqrt{n}^2) = O(n)$.↵
↵
Let's see the example.↵
↵
Let $op$ be $+$ (we calculate sum on the segment) and we have the following array $a$:↵
↵
`1 2 3 4 5 6 7 8 9`↵
↵
It will be divided onto three blocks: `1 2 3`, `4 5 6` and `7 8 9`.↵
↵
For first block _prefix-op_ is `1 3 6` and _suffix-op_ is `6 5 3`.↵
↵
For second block _prefix-op_ is `4 9 15` and _suffix-op_ is `15 11 6`.↵
↵
For third block _prefix-op_ is `7 15 24` and _suffix-op_ is `24 17 9`.↵
↵
$between$ array is:↵
↵
~~~~~↵
6 21 45↵
- 15 39↵
- - 24↵
~~~~~↵
↵
It's obvious to see that these arrays can be easily calculated in $O(n)$ time and memory.↵
↵
We already can answer some queries using these arrays. If the query doesn't fit into one block, we can divide it onto three parts: suffix of a block, then some segment of contiguous blocks and then prefix of some block. We can answer a query by dividing it into three parts and taking $op$ of some value from _suffix-op_, then some value from $between$, then some value from _prefix-op_.↵
↵
But if we have queries that entirely fit into one block, we cannot process them using these three arrays. So, we need to do something.↵
↵
## 2. Tree↵
↵
We cannot answer only the queries that entirely fit in one block. But what **if we build the same structure as described above for each block?** Yes, we can do it. And we do it recursively, until we reach the block size of $1$ or $2$. Answers for such blocks can be calculated easily in $O(1)$.↵
↵
So, we get a tree. Each node of the tree represents some segment of the array. Node that represents array segment with size $k$ has $\sqrt{k}$ children -- for each block. Also each node contains the three arrays described above for the segment it contains. The root of the tree represents the entire array. Nodes with segment lengths $1$ or $2$ are leaves.↵
↵
Also it's obvious that the radius of this tree is $O(\log \log n)$, because if some vertex of the tree represents an array with length $k$, then its children have length $\sqrt{k}$. $\log(\sqrt{k}) = \frac{\log{k}}{2}$, so $\log k$ decreases two times every layer of the tree and so its height is $O(\log \log n)$. The time for building and memory usage will be $O(n \cdot \log \log n)$, because every element of the array appears exactly once on each layer of the tree.↵
↵
Now we can answer the queries in $O(\log \log n)$. We can go down on the tree until we meet a segment with length $1$ or $2$ (answer for it can be calculated in $O(1)$ time) or meet the first segment in which our query doesn't fit entirely into one block. See the first section on how to answer the query in this case.↵
↵
OK, now we can do $O(\log \log n)$ per query. Can it be done faster?↵
↵
## 3. Optimizing the query complexity↵
↵
One of the most obvious optimization is to binary search the tree node we need. Using binary search, we can reach the $O(\log \log \log n)$ complexity per query. Can we do it even faster?↵
↵
The answer is yes. Let's assume the following two things:↵
↵
1. Each block size is a power of two.↵
2. All the blocks are equal on each layer.↵
↵
To reach this, we can add some zero elements to our array so that its size becomes a power of two.↵
↵
When we use this, some block sizes may become twice larger to be a power of two, but it still be $O(\sqrt{k})$ in size and we keep linear complexity for building the arrays in a segment.↵
↵
Now, we can easily check if the query fits entirely into a block with size $2^k$. Let's write the ranges of the query, $l$ and $r$ (we use 0-indexation) in binary form. For instance, let's assume $k=4, l=39, r=46$. The binary representation of $l$ and $r$ is:↵
↵
`l = 39(10) = 100111(2)`↵
↵
`r = 46(10) = 101110(2)`↵
↵
Remember that one layer contains segments of the equal size, and the block on one layer have also equal size (in our case, their size is $2^k = 2^4 = 16$. The blocks cover the array entirely, so the first block covers elements $(0 - 15)$ (`000000 - 001111` in binary), the second one covers elements $(16-31)$ (`010000 - 011111` in binary) and so on. We see that the indices of the positions covered by one block may differ only in $k$ (in our case, $4$) last bits. In our case $l$ and $r$ have equal bits except four lowest, so they lie in one block.↵
↵
So, we need to check if nothing more that $k$ smallest bits differ (or $l\ xor\ r$ doesn't exceed $2^k-1$).↵
↵
Using this observation, we can find a layer that is suitable to answer the query quickly. How to do this:↵
↵
1. For each $i$ that doesn't exceed the array size, we find the highest bit that is equal to $1$. To do this quickly, we use DP and a precalculated array.↵
↵
2. Now, for each $q(l, r)$ we find the highest bit of $l\ xor\ r$ and, using this information, it's easy to choose the layer on which we can process the query easily. We can also use a precalculated array here.↵
↵
For more details, see the code below.↵
↵
So, using this, we can answer the queries in $O(1)$ each. Hooray! :)↵
↵
# Conclusion↵
↵
We have a data structure that asymptotically answers the queries on a segment very fast. But, the constant of this data structures is big enough. Also it doesn't support changing the elements. But it can be modified to perform modification queries in something about $O(\sqrt{n})$ for modifying a single element. But in this case, query complexity becomes $O(\log \log n)$. You can think how to do this as an exercise.↵
↵
# Problems↵
↵
[https://www.codechef.com/NOV17/problems/SEGPROD](https://www.codechef.com/NOV17/problems/SEGPROD)↵
↵
# Code↵
↵
[Here it is](https://paste.ubuntu.com/263
↵
If you have some suggestions on how to improve this data structure or how to modify it, or something is written unclear and needs more explanation, feel free to write in the comments.↵
↵
**UPD**: As it's noticed in the [comment](#comment-406976), this algorithm (and some more optimal ones) can be found in [this article](https://pdfs.semanticscholar.org/cf74/0240d3a7440e23e92a09bf590cb70544cf4f.pdf) (thanks [user:Rafbill,2018-01-12]).↵
↵
**UPD2**: As [user:geniucos,2018-01-12] described in the [comment](#comment-407003), we can improve the time complexity to $O(n\log^* n)$ for preprocessing if $x\ op\ x$ applies. Let the block size is $O(\log n)$, not $O(\sqrt{n})$. We use a sparse table instead of $between$ array. We will have $O(\frac{n}{\log n})$ blocks and time complexity for building a sparse table will still be $O(\frac{n}{\log n}\cdot \log \frac{n}{\log n}) \approx O(\frac{n}{\log n}\cdot \log n) = O(n)$. The tree will have much smaller layers and we still have $O(1)$ per query.
↵
**UPD3**: The code is adjusted to work with non-commutative operations. The commutative property removed from the post.
