noshi91のメモ

データ構造のある風景

競プロで使うビットベクトル

はじめに

JOIの春合宿で簡潔データ構造の講義があり、競プロ界隈でも簡潔データ構造の機運が高まっているため(本当か?)、競プロで便利なビットベクトルの実装について書きます。

 

本記事で紹介する実装では、以下の性能を実現します。

 

bit列の長さをNとしたとき

空間    :6*N bit

構築    :O(N)

access:O(1)

rank    :O(loglogN)

select  :O(loglogN)

 

 

簡潔(N+o(N)bit)を諦めた理由として以下が挙げられます。

1.実装が重くなる

2.空間の定数倍がきついので、10^5程度だと言うほど省メモリでない

3.時間の定数倍が重い

この記事ではcompactで効率の良い構造を目指します。

selectについて実用レベルな定数時間の実装が難しかったためO(loglogN)で妥協しましたが、上手い実装を知っている方がいらっしゃったら教えて頂きたいです。

 

 

実装

f:id:noshi91:20180327184047p:plain

 

Nbit分はそのままのbit列を持ちます。これにより定数時間のaccessを実現します。

さらにNbitはrankやselectで使う累積和を持ちます。ここで注意するのは、全てのインデックスに対して累積和を持つとNlogNbit必要になってしまうことです。よって、列をlogN個づつに区切り各ブロックについて「列の先頭からそのブロックの頭までの1の数」を保持します。これによりNbitを達成します。

さて、ここまででrankがO(loglogN)で実行可能です。

累積和でブロックをはみ出さないギリギリの所まで求めた後、端数の部分をbit列に対してbitmaskとpopcountを行い計算します。popcountはO(loglogN)です。

 

※以下は1をselectする場合についての説明で、0もselectするためにもう2*Nbitのデータを持つ必要があります。

 

rankとは違い1ブロックにlogN個の1が入るように適当に分割し、それらのブロックの開始位置を配列で持ちます。ブロックは多くてもN/logN個なのでこの配列はNbitまでしか使用しません。

そして、サイズがlog^2Nを超えたブロックについてはブロック内の1の位置を単純に保持しておくことが出来ます(1つの位置を保持するのにlogNbit掛かるため)。よって、selectの際に求める場所に対応するブロックが疎ならこれを用いて計算します。

サイズがそれ以下のブロックについては、rankの際に用いた累積和のテーブルを用いて二分探索を行います。そのような密なブロックはサイズがlog^2N以下であることが保証されているので、累積和では計算できないlogNサイズのブロックに到達するまでにO(loglogN)回の計算を行い、そこからはbit演算でselectを行えばよいです。これもO(loglogN)なので全体でO(loglogN)でselectを行うことが出来ます。

いきなりrank用のテーブルで二分探索を行っても大して時間はかからない等の話はありますが、単純な計算回数なら半分程度になるので及第点でしょう。ランダムな(0,1が同程度の割合で出現する)bit列ならば二分探索の部分がほとんど不要なので、かなり高速になることが期待できます。

 

 

残念なお知らせ

競プロでビットベクトルを最もよく使うのはおそらくWaveletMatrixですが、これは基本的にrankしか使わないためselectを必死になって速くしてもあまり意味がありません(悲しい)。N=10^15が当たり前になってきたら日の目を見ることもあるかも。

 

 

実装例

つらい

どう考えてもバグっているため注意(verify用の問題が見つからず)