しえログ

qiita との使い分けに悩んでる

業務関係者

昼飯は久々にモスバーガー食べた。小学生の頃からチーズバーガーとフィッシュバーガーの計2つと決めているけど、変わらぬ味で未だに飽きがこなくて良い。体重と健康は良くない。

最近は広告にまつわる研究開発で酒飲ませて飯食わせてもらってるわけなんですが、1日のスケジュールがガラリと変わりまして。 これまでは

朝: 開発、昼: 開発、夜: 開発

だったのが

朝: サーベイ、昼: 開発・検証、夜: 論文読み・勉強

と、PC 画面はちょいちょい見つつもキーボードは叩いてない時間のほうが多くなりました。 想像はしてたのですが大学院いた頃とほぼ同じようなスケジュールですね。学生のときは活動開始が昼からだったけど。

想像してなかったことかつツラミといえばこんな異動してすぐのペーペーが社内外のステークホルダーと色々やりとりしつつ進めないと何も始まらないことが多いところ。こっちからしたら向こうはデータ提供者サマという立場なので仲悪くならない程度にこちらの要求を突きつけて行かにゃならないのは何かスキル認定されてもいいと思う。

おまけに胆力低すぎのコミュ障にとってはスラックで話しかけるのも一苦労だし、自分の事前知識が足らないおかげで「えっ」「えっ」みたいなやり取りすることもしばしばで。これまで自分が主体で管理することが多かったパブリッククラウドなどの検証用インフラ環境もいちいち他のグループ上長に許可取らなきゃだったりもらえる権限もアレだったりするのも輪をかけてたりする。まぁここいらはきっとそのうち慣れてくると信じたいが・・・。

研究開発といえば院時代もなんだかんだで最後の修論研究は医療画像システムだった。あのときの外部関係者は病院の心臓外科医の先生1人だった上に発案が向こうだったのでとても気が楽だったなぁ。今の片付いて次の研究に移るとしたらこっちがデータ提供元になったりしての産学連携とかやってみたいぞ。

ECCV2016 の Visual Relationship Detection with Language Priors メモ

ブログでは読んだ論文についても軽くメモっていければいいなとか。 最初はできるだけ読む本数増やしたいのでアブストのまとめを載せるだけで済ますのも多くなりそうだけど所詮自分メモなので悪しからず。


著者

Lu, Cewu and Krishna, Ranjay and Bernstein, Michael and Fei-Fei, Li

概要

  • 物体と述語のより頻繁な共起性をもとにそれらの視覚情報を学習し、それらにおける複数の関係性を予測するモデルを提案した
  • 言語系の先行研究をベースに関連研究を上回る成果を出した
  • 提案モデルは多くの関係性を数少ないサンプルから見つけ出した
  • 関係性を理解することが画像検索の改善に繋がったことを示した

手法

  1. 生画像から R-CNN で物体候補となる bouding box を検出
  2. visual appearance module(中で CNN を利用)と language module (中で word2vec を利用)という2つの提案モジュールでスコアリング
  3. 物体と関係性についてそれぞれのモジュールのパラメータを学習
  4. mAP で評価

所感

ちょろっとしか触れられていないけど訓練データにはない関係性を見つけ出す zero-shot learning も達成してるっぽい。 アルゴリズム擬似コードもありがたく掲載してくれているし自前で簡単な CNN でも組んだら実装してみるのも面白いかもしれない。

最近も頑張って色々やってる

先日超久々にブログを再開するぞ、と意気込んだはいいものの早速1つ前の記事が約20日前になってる。 今年は日記兼ねたこんなポエムも頻度高めに綴っていければいいなぁ。と毎年思ってる気がしなくもない。

早いもので会社で部署異動をしてから2ヶ月が過ぎ去りやがりました。 オフィスに安くて美味しいコーヒー淹れてくれるカフェがあったり自習に困らないぐらいの蔵書のある共有本棚に囲まれて生活できているおかげか新生活にもなんとか慣れてきた気がします。 正直異動だけでここまで周りの雰囲気が変わるとも思ってもいなかったので戸惑わないことも無いのですが会社のイチ歯車という意味ではやることやるだけなのでまぁ頑張っています。

そんなわけで最近やっていることをざっくりと。

  • 機械学習のお勉強
  • 画像処理のお勉強(コンピュータビジョン周り)
  • 統計のお勉強
  • 広告関連のお仕事
  • Python3
  • R

下2つのプログラム言語系以外は現チームメンバーからしたらすべてノービス状態です(正直 R もか・・・。 大学院に在籍していたころになんちゃってでやっていた画像処理周りの数少なすぎる知見のおかげでなんとかチーム内での人権は保てている気がするけど気を抜いたらすぐにやられそう。 サーバエンジニアやってた5年間の貯金も活かせないこともないのでしばらくはお賃金もらえるとは思うけども・・・。

勉強だけじゃなくてちゃんと研究もやりたいし面白い結果も残したいので古今東西の論文ちゃんと読まないとな。 学んだことを実際にコードでシミュレーションしてアウトプットするってのもなるべくやっていく1年にしたい。

安定結婚問題( Gale-Shapley アルゴリズム)

クリスマスだし、有名なマッチングアルゴリズムぐらい書いておこうと思って書いた。

安定結婚問題

安定結婚問題(あんていけっこんもんだい、英: stable marriage problem)とはデイヴィッド・ゲールと ロイド・シャプレイによって1962年に提示された問題である。 安定結婚問題は {\displaystyle n} n人の男性と {\displaystyle k} k人の女性、および、各個人の選好順序からなる。選好順序とは各個人の好みに基づき異性全員と自分自身を全順序で並べたリストである。ここで、「自分自身」とは誰とも結婚せずに独身のままでいることを意味し、「参加者全員が独身であるよりも望ましい相手と結婚している」マッチングは個人合理性(英: individuality rationality)を満たすと定義される。安定結婚問題の解は安定なマッチングである。安定結婚問題に対し、互いに現在組んでいる相手よりも好きであるペア(以下ブロッキングペアとする)が存在せず、全員が個人合理性を満たすマッチングを安定マッチング(英: stable matching)という。

安定結婚問題 - Wikipedia

シミュレーション

python3, numpy でやってみた。 無駄とバグはあるかもしれません。

n 人どうしのマッチングを考慮しており、各行ごとに 0 〜 n-1 をシャッフルした n 次正方行列を ndarray で生成し、ペアとなった結果を表示します。

n次正方行列による優先順位行列を用いて安定結婚問題を解くシミュレーション

結果

4人同士のマッチング

$ python3 gale_shapley.py 4
[[2 1 0 3]
 [0 2 3 1]
 [1 2 3 0]
 [2 0 3 1]]
[[1 2 0 3]
 [1 3 0 2]
 [0 2 3 1]
 [0 2 1 3]]
Engaged  (0, 2)
Engaged  (1, 0)
Engaged  (2, 1)
Already engaged  (0, 2)
Already engaged  (1, 0)
Engaged  (3, 3)
[[0 2]
 [1 0]
 [2 1]
 [3 3]]

5人同士のマッチング

$ python3 gale_shapley.py 5
[[3 4 2 0 1]
 [1 0 4 3 2]
 [0 4 3 1 2]
 [1 4 2 0 3]
 [0 4 2 1 3]]
[[3 2 4 1 0]
 [3 1 2 4 0]
 [2 1 4 0 3]
 [2 1 0 4 3]
 [0 1 3 4 2]]
Engaged  (0, 3)
Engaged  (1, 1)
Engaged  (2, 0)
Already engaged  (1, 1)
Discard  (1, 1)
Engaged  (3, 1)
Already engaged  (2, 0)
Engaged  (4, 4)
Already engaged  (3, 1)
Already engaged  (2, 0)
Already engaged  (4, 4)
Discard  (4, 4)
Engaged  (1, 4)
Already engaged  (2, 0)
Already engaged  (1, 4)
Engaged  (4, 2)
[[0 3]
 [1 4]
 [2 0]
 [3 1]
 [4 2]]

モンティホール問題シミュレーション

Python の勉強も兼ねて投稿。

モンティホール問題

「プレーヤーの前に閉まった3つのドアがあって、1つのドアの後ろには景品の新車が、2つのドアの後ろには、はずれを意味するヤギがいる。プレーヤーは新車のドアを当てると新車がもらえる。プレーヤーが1つのドアを選択した後、司会のモンティが残りのドアのうちヤギがいるドアを開けてヤギを見せる。

ここでプレーヤーは、最初に選んだドアを、残っている開けられていないドアに変更してもよいと言われる。プレーヤーはドアを変更すべきだろうか?」

モンティ・ホール問題 - Wikipedia

シミュレーションコード

実際にシミュレーションしてみる。 コードは Python の3系。

モンティホール問題シミューレション

結果

出力の一例。

$ python3 ./montyhall.py
No change:  0.33271
Change:  0.66709

ドアは変更しましょう。

プログラミングのための確率統計

プログラミングのための確率統計

DataNodeのConfigured Capacity

CDH4.2.0で。

HDFSのWebUIみたり、コマンドラインで
hdfs dfsadmin -report
したときに表示されるDataNodeごとのConfigured Capacity。

どうやら計算方法がdfs.datanode.data.dirに指定したディレクトリそれぞれに対してFile#getTotalSpace()を取得した値の合計をとっているらしい。

なので例えば、本番ではパーティション4つに分けるつもりでhdfs-site.xml設定したとして
それをテスト環境でも使いまわしたいときに同じパーティションに
ディレクトリを4つ作っただけだとConfigured Capacityは本来の4倍のサイズになる。

Used(GB)については単にduした値を合計しているらしく
こちらは本来の利用容量と変わりないため、その他の項目の計算に狂いが出てくる。
当然WebUIのUsed(%)のゲージもおかしくなり、パッと見での判断が辛い。

研修11/21

ロードシェアリング

  • DNS型不可分散
  • アドレス変換型(NAT)
  • ダイレクトルーティング
  • 振り分け方式
  • ラウンドロビン
  • ランダム型
  • 送信元IPアドレス
  • サーバ負荷連動型
  • 重み付け

DNSによる負荷分散

DNSバランス

  • BINDでのダイナミックDNSの設定

ロードシェアリング

  • 実サーバ
  • 仮想サーバ
  • Pound

IPVS

教科書

  • P.86-92
  • P.2-24~28