黄色本(PRML)は「機械学習」の本ではなく「ベイズ理論」の本である
タイトルはいささか暴論ですが。
私はもともとこの本を「機械学習の教科書」だと思って読み始めました。タイトルが『パターン認識と機械学習』ですからね。
最初に無理矢理読み通した感想は「難しい、良く分からない」というものでした。
ところが最近、ベイズ理論を勉強したいと思い、再びこの本を手に取ってみたところ……。
前回よく分からなかったところが、手に取るように分かるようになりました。
すべてが繋がって見えてくる。これは驚きです。
もちろんこの本がベイズ理論に基づいた統一的な視点から書かれた本であることは前文にも明記されており、副タイトルも「ベイズ理論による統計的予測」と書かれています。
しかしながら、この本の主テーマはむしろこの副題だと思うのです。「タイトルに偽りあり」と。
この副タイトルは実は日本語版にしかないそうで、翻訳した方が心ある方で「このタイトルだけではマズイ」と判断されたのでしょう。よく映画で「日本に持ってくると洋画に本来のタイトルとは違う無茶苦茶なタイトルをつけられてしまう」という問題が発生しますが、この本は逆で副題のほうが日本語版タイトルで良かったと思います。
「機械学習の本だ」と思って読むと「難しい」と感じ、
「ベイズ理論の本だ」と思って読むと「目から鱗がポロポロ落ちていく」。
そんな印象を受けました。
以前から「機械学習の勉強をするのならば、この本は最初に読むべきではない」と感じていたのですが、その理論的な根拠が得られたと思います。
この本は「機械学習」を「ベイズ理論」から「見直した」書籍であり、「ベイズ理論」を知らない、または勉強する気のない人間からすると極めて効率が悪い。「機械学習」と「ベイズ理論」の両方を一気に理解できる天才であれば良書なのでしょうが、普通の人はそうでないと思いますので、やはり他の機械学習本から勉強したほうがいいですし、私のようにベイズ理論を勉強したくなってから読んだほうが身につくと思います。
計画行列（デザイン行列）とは何か：PRML編
黄色本（『パターン認識と機械学習』：PRML）を読んでいると、「計画行列」という単語が頻繁に出てきます。
この計画行列ですが、英語では「design matrix」です。なので別書籍では「デザイン行列」と書かれていることもあります。
日本語で「デザイン」というと「意匠」のことをイメージしますが、もともとは「設計」の意味です。というわけで日本語の翻訳としても「設計行列」のほうが良かったような気がします。
この計画行列、もともとは統計学の生まれです。多種類の（重）回帰分析、（共）分散分析などの実験計画をモデル化して表すために作り出されました。たぶん「実験計画」が念頭にあったため「計画行列」という訳語になったものと思われます。
統計学的計画行列がよくまとまっているのがこちら。
デザイン行列（配置行列）* （「マルチメディア統計百科事典」より）
https://upo-net.ouj.ac.jp/tokei/xml/k3_04012.xml
こちらのサイトでは「デザイン行列」「配置行列」と表記されています。
対して、黄色本では計画行列Φを「基底関数φ_j(x_n)をN行M列に並べたもの」としています。ここでNは入力（及び目標値）の数、Mはモデルのパラメータ数です。
φ_0(x_1), φ_1(x_1),..., φ_M-1(x_1) φ_0(x_2), φ_1(x_2),..., φ_M-1(x_2) … … … … φ_0(x_N), φ_1(x_N),..., φ_M-1(x_N)
で、基底関数とは、「入力変数に関して非線形な関数」です。
この基底関数を線形結合させた「線形基底関数モデル」は、
・パラメータ(w)に関しては線形 ＝ 解析しやすい
・入力変数(x)に関しては非線形 ＝ 表現力が高い
という特徴を持つため非常に有用です。
つまり、黄色本において計画行列とは、具体的には
「（入力変数に関して非線形な関数である）基底関数をモデルのパラメータだけ右の列に並べ、更に入力変数の数だけ下の行に並べた行列」
であり、抽象的には
「当該の線形基底関数モデルを行列で表現したもの」
ということになります。
postgresqlの特定テーブルのみのバックアップ
なぜかpg_dumpを使ってpostgresqlの特定テーブルのみをバックアップするコマンドが、インターネット上で流布しているコマンドと実際のコマンドで違っていたのでメモ。
postgresqlのバージョンは8.4.20。
[ネット上でよく見かける（今回動かなかった）コマンド]
pg_dump -d データベース名 -t テーブル名 > 出力ファイル名
[マニュアルに書いてある（今回動いた）コマンド]
pg_dump -t テーブル名 -f 出力ファイル名 データベース名
CentOS上のEclipseにプラグインを一気にインストールしようとして失敗
CentOS6.7のEclipse(Helios)に下記の3プラグインを一気にインストールしようとするがエラーを起こして止まる。
・Marketplace Client
・Eclipse Java EE Developer Tools
・Eclipse Web Development Tools
"インストール・ダウンロード2" 中に内部エラーが発生しました。 Comparison method violates its general contract! インストールする項目の収集中にエラーが発生しました セッション・コンテキスト:(プロファイル=PlatformProfile、フェーズ=org.eclipse.equinox.internal.p2.engine.phases.Collect、オペランド=、アクション=)。 アーティファクトのダウンロード中に問題が発生しました: osgi.bundle,org.eclipse.wst.command.env,1.0.409.v201004211805. MD5 ハッシュは期待されたものではありません。期待: 84614d6c0969a44318eecdc5f0dc313e で 790c9c5660db33a19040b7bafd284cc3 を検出。
何度も失敗するので原因を調べようと、
1.Eclipse Java EE Developer Tools
2.Eclipse Web Development Tools
3.Marketplace Client
の順に一つずつインストールすると……
正常に終了しやがった！
なんでさ なんでさ ななななんでさ
(士郎ラップ)
python3.5をpython3のデフォルト設定にしたらUbuntuで「端末」が起動しなくなった件
ぐへえ、という感じ。
Ubuntu15.04で、apt-getでpython3.5をインストールしたのち、python3.5をpython3のデフォルトに設定しました。
cd /usr/bin sudo rm python3 sudo ln -s python3.5 python3
再起動したら「端末」が起動しない！？
Launcherを押しても、アプリケーションから呼び出しても、ショートカットを押しても起動しない。
慌てず騒がず Ctrl＋Alt＋F1キー でコンソールモードに移行してターミナルを起動。
何が起きているのか追いかけていきます。
DISPLAY=:0.0 gnome-terminal
したらエラーが出て、
Traceback (most recent call Last):
File "/usr/bin/gnome-terminal", line 9, in <module>
from gi.repository import Glib, Gio
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
from . import _gi
ImportError: cannot import name '_gi'は？ と思って/usr/bin/gnome-terminalを見に行ったら一行目が
#!/usr/bin/python3
お前python3のスクリプトなんかい！
だいたいオチが見えてきたので、python3のデフォルトをpython3.4に戻します。
cd /usr/bin sudo rm python3 sudo ln -s python3.4 python3
再起動したら「端末」が起動するようになりました。
一連のスクリプトがPython3.4用に作られていて、Python3.5では動かないものと思われます。UbuntuでPython3がこんなにシステムに密着しているとは思いませんでした。
調べてみたらaskubuntuに同じネタが載ってた。
terminal won't launch after install python 3.5
askubuntu.com
いやー焦りました。
じゃけんUbuntuでpython3.5使いたいときはanacondaで仮想環境使いましょうね～。
gensimのshow_topicsオプション（メモ）
Python用のトピックモデルライブラリgensimのshow_topicsメソッド内で用いられるオプションについて。
昔はこうだった
lda.show_topics(topics=10, topn=10):
今はこう
lda.show_topics(num_topics=10, num_words=10)
いま上のように書くと「そんなオプションは知らん！」とすげなくされる。
MeCabのparseToNodeのひどいバグ
pythonからMeCabのparseToNodeを使うと表層形（surface）がおかしい。printでも出てこないし型の判別すらできない。
頭を抱えながらpython-mecabの再インストールなどさんざんやってからこちらのサイトにたどりつく。
www.trifields.jp
（以下引用）
MeCabのバージョン0.996で、この方法によりPython3からMeCabのparseToNode関数を使うと、最初のsurface（表層形）が表示されないというバグがある。 (中略) このバグの最も簡単な回避策は、parseToNode関数を呼び出す前に、一度、parse関数を呼び出すことで回避することができる。
なんじゃそりゃあ！ という感じですがなんとか動きだしました。ありがとうございます。
