algorithm - 如何有效地从 Fenwick 树中找到连续范围的已用/空闲槽

Question

假设我正在跟踪 Fenwick 树中槽的使用情况。例如，让我们考虑跟踪 32 个槽，导致 Fenwick 树布局，如下图所示，其中网格中的数字表示基础数组中的索引，其中每个单元格中的值是 Fenwick 树操纵的计数该段中“已用”项的总和(即数组单元格 23 存储范围 [16-23] 中已用插槽的数量)。最低级别的项目(即单元格 0、2、4 ......)只能具有“1”(已用插槽)或“0”(空闲插槽)的值。

我正在寻找一种高效的算法来找到给定数量的连续空闲槽的第一个范围。

为了说明，假设我有下图中显示的 Fenwick 树，其中总共使用了 9 个槽(请注意，浅灰色数字只是为了清楚起见而添加的，实际上并未存储在树的数组单元格中)。

现在我想找到例如10 个空闲插槽的第一个连续范围，应该找到这个范围:

我似乎找不到一种有效的方法来执行此操作，这让我有点头疼。请注意，由于所需的存储空间量对我的目的至关重要，因此我不希望将设计扩展为线段树。

我们非常欢迎任何关于 O(log N) 类型解决方案的想法和建议。

编辑

赏金期到期后的更新时间。感谢所有评论、问题、建议和答案。他们让我重新思考，教会了我很多东西，并向我指出(再一次；有一天我可能会学到这一课)我应该在提问时更多地关注我想解决的问题。

自 @Erik P是唯一对包含请求的代码/伪代码的问题提供合理答案的人，他将获得赏金。

他还正确地指出，使用这种结构进行 O(log N) 搜索是不可能的。感谢@DanBjorge提供了让我思考最坏情况下性能的证据。

@EvgenyKluev的评论与回答让我意识到我应该以不同的方式提出我的问题。事实上，我已经在很大程度上按照他的建议做了(参见 https://gist.github.com/anonymous/7594508 - 这显示了我在发布这个问题之前被困在哪里)，并问了这个问题，希望有一种有效的方法来搜索连续的范围，从而防止改变这个设计成一个段树(这将需要额外的 1024 字节)。然而，这样的改变似乎是明智之举。

对于任何感兴趣的人，可以在此处找到与此问题中使用的示例匹配的二进制编码的芬威克树(以 64 位编码的 32 槽芬威克树):https://gist.github.com/anonymous/7594245 .

Answer 1

我认为以 O(log N) 时间复杂度实现所有所需功能并同时最小化内存需求的最简单方法是使用位向量来存储所有 0/1(空闲/已使用)值。位向量可以替代 Fenwick 树和线段树的 6 个最低层(如果实现为 64 位整数)。因此，这些树的高度可能会减少 6 倍，而每棵树的空间需求将比平时少 64(或 32)倍。

线段树可以实现为位于数组中的隐式二叉树(就像众所周知的最大堆实现一样)。索引为 1 的根节点，索引为 i 的节点的每个左后代位于 2*i，每个右后代 - 在 2*i+1。这意味着与 Fenwick 树相比需要两倍的空间，但由于树高减少了 6 层，这不是什么大问题。

每个线段树节点都应该存储一个值——从该节点覆盖的点开始的最长连续“空闲”槽序列的长度(如果没有这样的起点，则为零)。这使得搜索给定数量的连续零的第一个范围非常简单:从根开始，如果它包含的值大于或等于所需的值，则选择左后代，否则选择右后代。来到某个叶子节点后​​，检查位向量对应的字(字中间的一串零)。

更新操作比较复杂。当将一个值更改为“已使用”时，检查位向量的适当字，如果它是空的，则上升线段树找到一些左后代的非零值，然后下降到最右边的叶子与这个值，然后确定如何新added slot 将“free”区间分成两半，然后为 added slot 和被分割区间的起始节点更新所有父节点，同时在位向量中设置一个位。可以类似地实现将值更改为“免费”。

如果还需要获取某个范围内的非零项的数量，请在相同的位向量(但与线段树分开)上实现 Fenwick 树。 Fenwick 树的实现没有什么特别之处，除了将 6 个最低节点加在一起被位向量的某个字的“人口计数”操作代替。有关将 Fenwick 树与位向量一起使用的示例，请参见 Magic Board 的第一个解决方案。在 CodeChef 上。

可以使用各种按位技巧非常有效地实现位向量的所有必要操作。对于其中一些(前导/尾随零计数和总体计数)，您可以使用编译器内部函数或汇编指令(取决于目标体系结构)。

如果使用 64 位字和树节点实现位向量 - 使用 32 位字，除了位向量之外，两棵树都占用 150% 的空间。如果每个叶节点不是对应于单个位向量字，而是对应于一个小范围(4 或 8 个字)，则这可能会显着减少。对于 8 个字，树所需的额外空间仅为位向量大小的 20%。这使得实现稍微复杂一些。如果优化得当，性能应该与每个叶节点一个单词的变体大致相同。对于非常大的数据集，性能可能会更好(因为位向量计算比遍历树对缓存更友好)。