Poster Session
今年からJob Fairというのが始まったようで、午前中Speakerセッションがなかったので、Poster Sessionを聞きに行きました。Sphinxの中の方々がいらっしゃって、少しお話できました。Sphinxには仕事でお世話になっているので、近いうち自分からも事例報告のようなことができたらな、と思っています。
それから昨日一番早い時間の発表でDeep Learningのお話をしていたTanakaさんがプロジェクト・マーという別のプロジェクトをやってらっしゃるそうで、少しお邪魔しました。月面などの写真から、人面の部分を機械学習を使って発見するそうです。研究室時代に人工衛星で地上を撮影した狭い範囲の写真から、Google Mapで緯度経度を見つけてくる泥臭い作業をやっていたのを思い出してしまいました。Deep Learningなんかで人の顔写真を学習データとしてマッチングを行うと精度がよすぎるので、むしろある程度ノイズを載せてあげたほうが、宇宙人みたいな顔が見つけられて面白いらしいです。わかります、ロマンは人を動かす。
Oktavia - Search Engine
Oktaviaというサーチエンジンを開発されている方のお話。Sphinxのドキュメントサーチを置き換えるのがプロジェクトの目標だそう。基本的に現存するサーチエンジンの多くは転置インデックス方式なんですが、FMインデックスという手法を使うことで検索の高速化をはかっています。以前情報検索アルゴリズムを勉強し際にちょっと触れたことがあるんですが、すっかり忘れてしまっていたので再勉強が必要そうです。発表でも共有されていた、高速文字列解析の世界(PFIの岡野原さんの著書です)、こちらも良さげですね。パッケージングの今
毎年似たような内容で発表されているそう。pythonにはsetuptoolsを入れると使えるeasy_installとpipがありますが、そのあたりのお話。
これまで、pipを入れるためには先にez_setup.pyからsetuptoolsのインストールが必要でしたが、いまはget-pip.pyというので直接pipがインストールできるそうです。また、python3.4だと標準でpipがインストールされるんだとか。setuptoolsはいらない子やったんや!\(^o^)/
あとは自分で作ったライブラリなどのパッケージングのやり方も紹介してくださいました。ちょうど今作っているプロダクトの一部を切り離してライブラリにしようと考えていたのでとてもありがたいお話でした。
パッケージングの今 from Atsushi Odagiri
正規表現リテラルは本当に必要なのか?
pythonにもsedで書かれるようなs/original/replace/gのような正規表現リテラルを導入したほうが良いのか?という問題提起のお話で、とても身近な話なので大変聴きやすく、面白かったです。perlやjavascriptなんかでは文字列リテラルが使えるわけですが、pythonにも必要なのでしょうか?誰しもこれがあればもっと楽に書けるのに、といった経験はあるのではないでしょうか。スピーカーの方がおっしゃってたように、言語仕様が複雑になってしまうという大きなデメリットがあるし、自分のユースケースの場合現状の文字列関数でさほど苦労していなかったり、Pythonで文字列処理をする場合はほかのコマンドで処理したものを入力したりするためにあまり困ることがないので、個人的には必要ないと思っています。
それから、reモジュールを使う際、何度も使う正規表現はre.compileによって先にpatternをコンパイルしておく、という使い方をしますが、これはre.searchで毎回正規表現を指定すると何度もコンパイルが走って無駄だからと思っておりました。しかし内部の実装を見ると、re.searchやre.matchで_compileというメソッドを呼び出しており、これは
となっています。すなわち、基本的にキャッシュが効くので内部で明示的にre.compileと同じように処理されるわけです。これは目から鱗でした。ただ、当然キャッシュが増えすぎるとパージが発生してしまい、compileの処理だけでなくキャッシュに対するIOのオーバーヘッドが大きくなるので気をつける必要があります。
ということで総括すると、今年は去年以上に持ち帰るものが多かったPyConでした。
最後のLTから写真撮影、抽選会(なんとPepperくんが当選番号を選んでくれる!!)まで終始アットホームな雰囲気でした。2年連続して参加してみると主催側の人の顔ぶれもわかってきたりしてより身近に感じられます。来年も、必ずいきます!
それから、reモジュールを使う際、何度も使う正規表現はre.compileによって先にpatternをコンパイルしておく、という使い方をしますが、これはre.searchで毎回正規表現を指定すると何度もコンパイルが走って無駄だからと思っておりました。しかし内部の実装を見ると、re.searchやre.matchで_compileというメソッドを呼び出しており、これは
def _compile(*key):
cachekey = (type(key[0]),) + key
p = _cache.get(cachekey)
// 以下略
となっています。すなわち、基本的にキャッシュが効くので内部で明示的にre.compileと同じように処理されるわけです。これは目から鱗でした。ただ、当然キャッシュが増えすぎるとパージが発生してしまい、compileの処理だけでなくキャッシュに対するIOのオーバーヘッドが大きくなるので気をつける必要があります。
ということで総括すると、今年は去年以上に持ち帰るものが多かったPyConでした。
最後のLTから写真撮影、抽選会(なんとPepperくんが当選番号を選んでくれる!!)まで終始アットホームな雰囲気でした。2年連続して参加してみると主催側の人の顔ぶれもわかってきたりしてより身近に感じられます。来年も、必ずいきます!
0 件のコメント:
コメントを投稿