春山 征吾のくけー

https://www.unixuser.org/~haruyama/blog/ に移転しました http://wiki.livedoor.jp/haruyama_seigo/d/FrontPage @haruyama タイトルが思いつかないときはそのときかかってた曲をタイトルにしています.

「イラストで学ぶ機械学習」のMATLABコードを全部試した

他の感想ページ:

イラストで学ぶ 機械学習 最小二乗法による識別モデル学習を中心に 杉山将 講談社 は, 発展的な話題を扱っているにもかかわらずサンプルコードが付いている貴重な本である. 残念ながらそのサンプルコードにはいくつか問題があったので, 後から学習する人に取って有用なようにメモを残しておく.

対象は 2013/09/20 発行第1刷.

MATLAB 向けのコードだが GNU Octave, version 3.6.4 にて試した. Octaveには 以下の既知の問題がある.

うまく動かないコード:

  • 図3.2: for内の2行目の p は スモールpでなく ラージP
  • 図4.14: u~=i ないし u!=1 であるべき箇所で ~ ないし ! が消えている
  • 図5.8, 図6.14: t0 の要素に0に近い値が入ると pinv()が正常に動作しない. 0に近い値を先に 0 にしておくことで対処した. もしかしたら MATLAB ではうまくうごくのかもしれない.
  • 図14.3: グラフの表示コードがない
  • 図18.6, 18.11: g の初期化コードがない.

最初の6つのコードのうち3つがそのままでは動かないので先がおもいやられたが, 全体としてはそこまでやばくはなかった.

学習者の間口を広げるために MATLABのサンプルコードはできれば Octave でも問題ないものにしてもらえるとありがたいがしょうがないところだろう.

Sublime Text の BracketHighlighter がうらやましかったので haruyama/vim-matchopenを作った.

Sublime Textfacelessuser/BracketHighlighter というプラグインがあります. SICP読書会の発表者の方が使っていてかっこよかったので Vim で真似する方法を探しましたがぴったりなのはありませんでした.

ぴったりではありませんが, arnar/vim-matchopen が希望に近いものでした. これを fork して haruyama/vim-matchopen を作りました.

facelessuser/BracketHighlighter ほど高機能ではありません. (), {}, <> について, カーソル位置の文脈での開きカッコと閉じカッコをハイライトします.

会社の人何人かに試してもらって, searchpairpos() に timeout を付けないとえらい重くなることがわかったので, timeout を付けました. ありがとうございました.

もっといいものがあれば乗りかえたいですが, 自分ではそれなりに満足しています.

dynabook KIRA V832/W2UHS に Ubuntu を入れてつかっています.

13.3 のサイズで高解像度の液晶のマシンは夏モデルでもなさそうだったので買いました.

にまとめている通り, Ubuntu を入れてつかっています. サスペンド以外のほとんどすべての機能が使えています.

起動にかかる時間やハイバネートや復帰の時間が前に使っていた HDD なノートPCよりもかなり速くていいです.

電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したい その2

春山 征吾のくけー : 電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したい - livedoor Blog(ブログ) では ソートしたんですが, 1億件の電話番号に対して ハッシュの頭文字で 16分割したファイル(各625万行ほど)を作ると, ソートしないで grep でもすぐ結果が返ってきました. これらのファイルを作るのに直列にやって 8分台でした.

単にあるハッシュ値と一致する電話番号探すだけなら, ファイルIOがない分速いです. 1億件は 2,3分で終わります. もちろん並列にやったり GPU 使えばもっと速いです.

電話番号みたいな狭い空間の単なるハッシュ値は, 少しの手間で復元できます. セキュリティに関する目的に利用してはいけません.

080[0-9]{8} な 電話番号のハッシュ値と番号を記述したファイル群

https://app.sugarsync.com/wf/D1955203_142_7316730

ファイル作成に利用したスクリプト

haruyama/tel_hash ・ GitHub

電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したい

昨日 2013/03/20に突然 電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したくなりました.

とりあえず 080[0-9]{8} 形式の電話番号のすべてについて,

"ハッシュ値(16進)\t電話番号\n"

なソート済みファイルを作りました. 全部で 4.2GB になりました.

手元の計算機で, 電話番号からハッシュ値の計算に数分, ソートに30分, 分割に数分といったところです.

2013/03/21 追記: ハッシュ値の頭文字で16分割し 625万行ずつのファイルにすると ソートせずに grep しても余裕でした. 時間も1億件やるのに8分台です. ちなみに単に1つのハッシュ値を照合するだけならファイルIOがないので総当たりで3分もかかりません. 春山 征吾のくけー : 電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したい その2 - livedoor Blog(ブログ) で詳述してます.

unixuser であればlook(1) で高速に検索できます. 手元のDebian sid(x86_64, bsdmainutils 9.0.4)の look(1) は どうやら 1GB 以上のファイルを扱えないようなので, 2500万行ずつの4ファイルに分割しました. 1ファイルに対する検索は(エントリがあれば)2秒くらいで終わります.

ファイルをどこかで公開しようと思いましたが, 1GB(bzip -9 で圧縮しても 300MB以上になります)のファイルを置けて公開できるサービスがすぐにみつからなかったのでまだしていません.

電話番号には, 070 や 090, 固定電話がまだありますし, 表記としても ハイフン区切りあるなしがあります.

ハッシュ関数もMD5以外に多数あります. 汎用的にするにはもっと空間効率のよいデータ構造を利用したほうがよさそうです(レインボーテーブルなりなんなり).

とはいえ, ある1つのサブシステムで利用される表記やハッシュ関数は通常1つであり, 携帯の電話番号に限ってしまえばこの方法でも十分いけるでしょう.

渋谷.clj 2012/12/23(日) を開催します. #渋谷clj

どうにか人数が集まったので 渋谷.clj 2012/12/23(日) on Zusaar を開催します. ミクシィの会議室を使います.

参加者はまだまだ募集中です. Clojure 書きましょう!

Anuenue-0.8.1 と StandardPlusTokenizer

2012/12/17 anuenue-wrapper - A Search Package with Apache Solr - Google Project Hosting 0.8.1 をリリースしました.

0.8.1 では, デフォルトのcore で拙作の StandardPlusTokenizer を利用できるようにしました.

Lucene/SolrのStandardTokenizerは, 記号などの文字を捨ててしまいます. 「つのだ☆ひろ」の「☆」がなくなっているのが見えます.

text_cjk

StandardPlusTokenizer は, 空白文字以外の文字をすべて切りだします. 「つのだ☆ひろ」の「☆」は残ります.

text_cjk_plus

2012/10/21 渋谷.clj を開催しました. #渋谷clj

2012/10/21 渋谷.clj を開催しました.

渋谷.clj 2012/10/21(日) on Zusaar

20人ほどの参加者にお越しいただき, もくもくと Clojure を書きました.

私は haruyama/mixi-cj-lib ・ GitHub の Lucene を用いたTokenize部分の改良をしました. 当日はなぜか会社の無線LANにしばらく繋がらなくなって原因を究明するのに手間取ったりして2時間ほどしかもくもくできず, 想定していた機能をすべて実装できませんでした. 今日 10/23 に一通り終えました.

kuromoji だけが使える状態からその他の TokenizerFactory を利用できるようにマクロを用いたり,

TokenizerFactory と Analyzer を区別なく扱うために defmulti を利用しました.

https://github.com/haruyama/mixi-cj-lib/blob/a884443007e25928145b47f96e186d656dd3c772/src/mixi/lucene/analysis.clj

19時以降は懇親会を開催し, こちらも10人以上の方にご参加頂きました. Clojure に関係する話で大いに盛り上りました.

次回は 12月か1月にやりたいところです.

標本と母集団とニュース

瞬刊!リサーチNEWS というサイトを前職の 株式会社VOYAGE GROUP(旧ECナビ) が作った. 私は問題が多いサイトだと思う. 問題のうち1つを紹介する.

瞬刊!リサーチNEWS のネタはリサーチパネルのアンケート結果だ. リサーチパネルのアンケート回答者は, リサーチパネルの会員に限定される.

リサーチパネル が知りたい母集団の情報は, アンケートによって様々だ. アンケートによっては特定の行動(買い物など)をした人のみを対象とする場合もある. だが, [[瞬刊!リサーチNEWS>h ttp://shunkan-news.com/]] が知りたい母集団は基本日本に居住する者だと思われるので, ここでは母集団は, 日本に居住する者だとする.

リサーチパネル の会員は, インターネットをそれなりに利用していてポイントを欲しい人というのが多いと思われる. リサーチパネル のアンケートで取られる標本は, 会員による偏りがかなりかかっている.

標本による偏りがあることはしょうがない しかし, 母集団を標本が代表しているかについて標本を利用する者は意識しなければならない.

瞬刊!リサーチNEWS はそのような意識がないようだ. リサーチパネル のアンケートの結果をそのまま日本に居住する者の意見であると見なしているように思える. 2012/10/01 21時現在のタイトルをみると以下のような断定的な表現がみられる.

無意識にそうしているのか意識的にそうしているのかわからないが, これは媒体として好ましいことでない. ある限られた層の意見を検証なしに全体の意見のように伝える扇情的な媒体が淘汰されることを望む.

外部のログ分析サービスに個人を特定したり名寄せできる情報を送らないようにしよう

最近, いろいろなログ分析サービスが出現しており, 私が直接知っている方が関わっているものも2つある.

  • soleami
  • Treasure Data
    • ログ分析サービスというわけではないが, 現在の主な用途はログ分析だと思われる.

これらのサービスに, 顧客のIPアドレスやユーザエージェント, 携帯電話の契約者Idを渡すのは好ましくない. サービス側による個人の特定や名寄せ, もしくはサービス側から情報が漏れた場合に第三者による特定や名寄せが行なわれる可能性がある.

これは Google Analyticsなどでも同様であるが, 情報の扱いについてのヘルプがあり, これに同意して導入者が情報を提供している. また『Google Analytics の使用を完全に開示するプライバシー ポリシーを用意する必要があります。』 となっており, プライバシーへの配慮が見られる.

しかし, 前述の2つのサービスではそこまでの配慮は見られない.

soleamiの利用規約では

第7条(利用者のデータの統計処理活用)

ロンウイットは、データ解析のために、利用者がアップロードしたファイルを自由に利用することができるものとします。

ロンウイットは、利用者が特定されない方法によって、統計処理された解析データを本サービス以外でも利用することができるものとします。

と書かれている. ここでの利用者はログ提供者であってログ提供者のサービス利用者ではない.

Terms of Service | Treasure Data では,

3.1 Use of Collected Data. You represent and warrant that (a) you have the right to provide to us the Collected Data and we have the right to use such Collected Data in the manner described in these Terms; (b) your use and transmission of Collected Data is and will be in compliance with these Terms, and all applicable laws, regulations, and ordinances, including relevant data privacy laws; and (c) you have provided all necessary notices and obtained all necessary consents related to the collection and use of such Collected Data in the manner described in these Terms. We reserve the right to review and/or remove any Customer Data if we suspect that it is in violation of these Terms and/or applicable laws. We will only access and use the Collected Data to the extent it is necessary to provide the Service to you. Notwithstanding the foregoing, we may use the Collected Data for the purpose of generally maintaining and improving the Service as well as for developing and distributing general benchmarks or statistics pertaining to the Service, provided the Collected Data is used in the aggregate and is in anonymized form.

と書かれている. 制限事項はあるが明快とはいえない.

とはいえ, これらのサービスは便利であり利用したい人も多いだろう. その場合は, 個人を特定したり名寄せできる情報を送らないようにしてしまうのが無難である.

  • soleami の場合は Solr が直接インターネットからのアクセスを受け付けない構成になっているサービスが多いと思われ(Webサーバがインターネットからのアクセスを受け, Solrに転送する), この場合はサービス利用者の情報は検索クエリだけに限定されるので問題とはならないだろう.
  • Treasure Data では, すでに IPアドレスやUserAgent, さらには携帯の契約者Idの単なるSHA1値を転送している例がある.
    • 携帯の契約者Id については Fluentd meetup #2 32ページ
      • 携帯の契約者Id の部分的なリストの入手は携帯向けサービスを行なえば容易であり, SHA1 だけでは名寄せや逆引きを防げない.
  • 参考: プライバシーとIPアドレス によると IPアドレスだけでも個人情報となる国がある. 利用者のIPアドレスをクラウドベースのサービスに提供するのは慎重になったほうがよいだろう.
  • 個人を特定したり名寄せできる情報ベースでの分析を行ないたい場合は, 直接のその値を用いず外部から推測できない別のIdに変換してから送ればよい. ただし 前述の契約者IdのSHA1値のような結局特定/名寄せ可能な方式ではだめだ.
QRコード
QRコード
  • ライブドアブログ