NumPy関数だけでTopKを求め、多次元のインデックスをスライスするための方法
NumPy関数を使って多次元配列のTopKを求める方法を検証します。PyTorchの関数を使えば簡単にできますが、NumPyだけで行う場合は工夫が必要です。いつも忘れるので自分用忘備録に
目次
PyTorchだと簡単だけどNumPyだと一筋縄ではないかないTopK
TopKというのは、上位○個の要素を求めてねという処理です。PyTorchだとこれはtorch.topkという専用の関数を使えば楽勝で、
列ごとに独立して上位2個の要素を求めているのがポイントです。
これをNumPyでも実装したいのですが、NumPyにはTopKの関数がありません。さてどう実装するでしょうか?
np.argpartition+np.take_along_axisでやる
こちらの記事を参考にしました。
np.argpartition
np.argpartitionという関数を初めて知りました。簡単にいうと、np.argsortの完全にソートしない場合で、大まかなブロック単位で大小判定できていれば良しとするときに使える関数です。具体的にはTopKをとって、合計や平均をとるときに使えます(足し算は順序入れ替えても変わらないので)。完全にソートしなくていいので、計算量的に軽いということでしょう。
この関数理解するのが難しいので、1次元の例で説明します。
np.argsortは文字通り完全にソートした場合でGround Truthにあたります。次にnp.argpartitionの第2引数を変えた場合に、どのように出力が変化するかを確かめます。
Ground Truthとの関係に注目しましょう。第二引数のインデックスの場所に仕切りをおきます
np.argpartitionのお気持ちは、「仕切りの左と右で、個々のインデックスの順序は違うけど、仕切りレベルでの大小は会っていますよね?」ということです。
例えば0のケースでは、「5」が最初にきているのはあっています。その他の順番はいい加減です。
例えば1のケースでは、仕切りの左側「5、4」がきているのはあっています。ここは「4、5」がくることもあります。仕切りの左側と右側での大小関係のみみていて、仕切り内の順序はみていません。
わかりやすいのが3のケースで、仕切りの左側は「4、5、7、2」となっていますが、Ground Truthは「5、4、7、2」です。順序は異なっていますが、仕切りの左側の構成要素は同じです。
「partition」というのは仕切りという意味なので、文字通りの意味ですね。
負のインデックスにすると降順にできる
第二引数に負のインデックスを入れると降順にできます。やってみましょう。
出力にこちらで仕切りを入れています。
このような感じになります。同一値のときにインデックスがどうなるのか興味はありますが、ざっくりと求めたいときは便利でしょう。
これが何に使えるか
TopKをとったあと合計や平均をとりたいときに使えます。足し算は交換法則が成り立つので、
のように順序がランダムでも結果は一緒です。
2次元以上の場合
2次元以上の場合は返ってくるインデックスが多次元配列になります。
仕切り線をこちらで追加しました。
こういう状態です。Argsortの結果と見比べてください。
np.take_along_axis
多次元配列の場合のインデックスの扱いがまた曲者です。単にスライスするとShapeが想定していないものになります
3階テンソルになってしまいました。これはおかしいです。
「インデックスはaxis=0方向にとってほしい」ということなので、スライスではなく、np.take_along_axisという関数を使います。
上の各3行分が、各行の最小値側の3要素です。argpartitionを使っているので順番は保証されません。
結局TopKってどうやるの?
K=2の場合
K=5の場合、
となります。
値の妥当性
そもそもこれうまくいっているのでしょうか? argsortした場合と、argpartitionの場合で、TopKとったあとのaxis=0の平均をみてみます。
それぞれ「np.argpartition」でとったTopK、「np.argsort」でとったTopKです。この2つのmeanの結果がすべて同じなら出力が100(100回試行)になります。結果は、
となり、無事一致しました。
パフォーマンス比較
np.argpartitionはおそらく速いだろうということでしたが、実際に検証してみます。
環境:Colab CPU
コード
行数とTopKの割合を変えて、各パターン100回試行した平均値を計算します。
np.argpartitionの場合
行数/K_ratio | 100 | 10 | 2 |
---|---|---|---|
100 | 0.00062 | 0.00211 | 0.00246 |
1000 | 0.03382 | 0.03386 | 0.03826 |
10000 | 0.25718 | 0.27161 | 0.30098 |
100000 | 5.22519 | 5.31681 | 5.61820 |
np.argsortの場合
行数/K_ratio | 100 | 10 | 2 |
---|---|---|---|
100 | 0.00458 | 0.00444 | 0.00453 |
1000 | 0.08250 | 0.08663 | 0.08135 |
10000 | 1.24387 | 1.23313 | 1.24913 |
100000 | 16.00673 | 15.58112 | 15.85248 |
倍率
倍率 | 100 | 10 | 2 |
---|---|---|---|
100 | 7.36275 | 2.10258 | 1.84095 |
1000 | 2.43963 | 2.55878 | 2.12604 |
10000 | 4.83663 | 4.54015 | 4.15025 |
100000 | 3.06338 | 2.93054 | 2.82163 |
やはり計算量のオーダーが異なり、np.argpartitionのほうが3倍~7倍程度速いです。np.argpartitionのいいところは、TopKのKの割合が少なければ、高速化がかかってくれるということです。argsortの場合は全体をソートしてしまうため、Kの割合に関係なく計算量は一定となります。
1万個ぐらいの要素に対してTopKをとる操作は、少し混みいったモデルを作ると普通に出てくるので、使いこなすと便利だと思います。
Shikoan's ML Blogの中の人が運営しているサークル「じゅ~しぃ~すくりぷと」の本のご案内
技術書コーナー