第2回 Tokyo.SciPy で「数式を numpy に落としこむコツ」を発表してきました

10/15 に IBM さんの渋谷オフィスにて開催された 第2回 Tokyo.SciPy にのこのこ参加してきました。主催の @sla さんはじめ、参加者・発表者各位おつかれさまでした&ありがとうございました。


せっかく行くならなんか発表したいよね、ということで「数式を numpy に落としこむコツ 〜機械学習を題材に〜」なんてタイトルで、数式(あるいは数式入りのアルゴリズム)を実装するときに、どういう点に注目すれば易しくコードを書けるか、についてちらちら語ってみた。
こちらがその資料。



例えば、機械学習の(多クラス)ロジスティック回帰という技術では、次のような数式が登場する。

  • \nabla_{\bf{w}_j}E(\bf{w}_1, \cdots, \bf{w}_K)=\sum_{n=1}^N(y_{nj}-t_{nj})\phi_n   (PRML (4.109) 式)

これを一目見てすらすらとコードが書けるなら苦労はないが、慣れている人でないとなかなかそういうわけにはいかない。実際にはもっと複雑な式が登場することも珍しくない。
でも実は、ある方針でちゃんと考えれば、かんたんに(!)誰でも(!!)実装できる。機械学習の知識も不要。
種明かしは資料にて。


ところで。


発表の冒頭や途中で、「泥臭いコードを書いてしまったらなんかダメな気がするかもしれないけど、全然そんなことない。なにより一番困るのは、コードを組めない動かないということ。だから、まずできるだけ簡潔に実装できるようになる、そのために手強い数式にぶつかったらどのように考えればいいかということをみていきましょう」という趣旨のおことわりを何度も繰り返し言わせてもらっていたのだが、それにもかかわらず「そのコードは遅いですよね」と突っ込まれてしまった。
もちろん速いコードの方が嬉しいに決まっているが、そんなことはコードが動いてから考えればいいと個人的には思っている。動かして、プロファイルを取って、ボトルネック部を改良する。一回しか走らないところを1秒早くしたってしょうがないし、そもそも速度的に十分なら何もする必要がない。
現実問題としても、スパースであるとか、値が取り得る範囲が決まっているとか、単精度で十分とか、そういった事前知識類を使ってアルゴリズム自体やデータ構造を工夫した方がはるかに効果的なんだし。


速度が遅いと思ったら前提はさておき突っ込まざるを得ない、というのが numpy 圏の文化なのかもしれない。
発表冒頭の自己紹介の流れの中で*1、以前 Tsukuba.R にて「RかわいいよR」というライトニングトーク(若干語弊あり)をしたりしてたことに触れて、numpy コミュニティはアウェイみたいですけどがんばりますw 的な冗談(もちろん冗談ですよ!)を言ってみたりしたのだが、よっぽど深刻なアウェイっぷり(個人的には、コード片の速度最適化よりも簡潔さ&間違いにくさの方が全然重要)と直面するハメになってしまって、予想外にびっくりしたというのが正直なところ。
まあそもそも「 Python でも R でも Ruby でも Java でも C++ でも、やりたいことに一番合うプラットホームを都度都度選べばいいんじゃね?」という考え方の人間が、特定プラットホームについての勉強会に行くのは、最初からアウェイに決まってるような気がしないでもない(苦笑)。


終了後は懇親会を経て、さらに同日開催されていた さくさくテキストマイニングの懇親会に合流することに。
いつも定員いっぱい大人気の さくテキには遠慮して参加したこと無かったので、さくテキクラスタとは初めての交流。
眠くていろいろ憶えてないが(ぉぃ)、AR な話がたくさんでてておもしろかった。

*1:いつもの通り、公開資料から自己紹介パートは削除してます。自己紹介をまき散らすのってなんか気恥ずかしくて〜