Ubuntuでグラフィクドライバ入れなおしたらスプラッシュスクリーンから進まなくなった

cuda使いたくて、ゲーミングノートにubuntu入れたあと、グラフィクドライバをアンインストールして最新のに入れ替えて再起動したらスプラッシュスクリーンから進まなくなった。
一応画面は写ってるわけで、まったくGPUを認識できないわけではない。
困ってググったらドンピシャの回答発見

askubuntu.com

grubに解像度を教えてあげれば良いみたい。
hwinfoは14.04LTSのリポには入ってないようなので、xrandrで解像度を調べる。

ubuntuforums.org

$ xrandr

解像度がわかったら、grubの設定を書き換え

sudo vim /etc/default/grub
行追加
GRUB_GFXPAYLOAD_LINUX=1024x768 <--対応してる解像度を入れる

最後におまじない

echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-grub2
sudo update-initramfs -u

Golden riceの現在

「難消化米」で糖分吸収抑え肥満予防−沖縄科学技術大学院大学のコメ開発に注目集まる:日刊工業新聞

この記事を見て、悠長なものだなーと思いつつ、遺伝子組み換え米のgolden riceを思い出してググった。
ちなみにGolden riceってのは、記憶だと人参由来のビタミンAを生産できる遺伝子を米に組み込んだもので、主に途上国で栄養不良になりがちな人々向けに作られている。詳しくはググってね。

www.goldenrice.org

一時は遺伝子組み換え作物反対派によってプロジェクト頓挫の危機にあったが、今は環境団体のグリーンピースを味方につけて形勢逆転した模様。それどころか反対派のせいで救えたはずの命が救えなかった、その責任は反対派にあるのではないか、などと攻めに転じている様子。
やっこさんはアグレッシブである。

あとこのビデオのオッサン鼻毛出てるな。

www.allowgoldenricenow.org

Kohonenの自己組織化マップをpythonで実装

Kohonenの自己組織化マップ(Self Organizing Map, SOM)をpythonで実装してみた。
SOMの元論文はKohonen1982*1
以下の説明と実装はAI Junkieの平易な解説を参考にしている。
http://www.ai-junkie.com/ann/som/som1.html


実装したpythonのコードはgithubにあります。
https://github.com/latboy/som-in-python


SOMとは?

一般の大きな次元のデータ群を、それらの特徴に基いて、低次元(典型的には1〜2次元)空間に配置する方法。似ているもの(データベクトルがベクトル空間上で近いもの)同士が、低次元空間でも互いに近い位置にマップされるようになる。
ここで、アルゴリズム自身にはデータ量の特徴を与える必要がない。以下に述べる単純で再帰的なアルゴリズムで、データの特徴をとらえた低次元マップが得られる。すなわち、これは1種の教師なし学習である。
また、一つのユニットに収められているベクトルは、マップ上のその位置が表す特徴をもった典型的なベクトルであるので、SOMは一種の生成モデルと言っても良いと思う。

アルゴリズムの概要

分析したいデータが、D次元のベクトルの集合として与えられたとしよう。これを2次元平面にマップする方法を与える。
まず、D次元の要素を持ったユニットを、2次元空間に配置する(競合層と呼ぶ)。各ユニットの値は適当な乱数によって初期化しておく。
この時、データの集合に対して、次の操作を繰り返す。

  1. あるデータに対し、それと最も似ている(D次元空間でユークリッド距離の近い)ベクトルを持つユニットを探す。(そのようなユニットをBMU: Best Matching Unitという)
  2. BMUとBMUの近傍のユニットを、与えられたデータに近づくよう更新

実際には学習過程におけるパラメータの調整など細かな注意がある。
BMUの更新規則から、頻出するベクトルの特徴が強く競合層に学習される。
また、BMUだけでなく、BMUの近傍ユニットも入ってきたベクトルに近づけるため、競合層において近い位置にあるユニット同士が、似た特徴のベクトルを持つようになる。

実装

今回は3次元のランダムに生成した実ベクトル V \in [0,1)^3 を2次元の競合層にマップする実験を行った。
2次元平面上の座標を \vec xと表し、その上の N^2個のユニットを W(\vec x) と表すと、
更新式は次のように与えられる。
{ 
W_{t+1}(\vec x) = W_t(\vec x) + \Theta(\vec x, t) L(t) (V_t-W_t(\vec x))
}
ここで添字 tは学習ステップ(計算機時間)であり、t=0からVのサンプル数までを走る。
右辺の括弧の中が、入力ベクトルと、あるユニットに格納されていたベクトルとの誤差を表している。
ここで、学習パラメータ \Theta(t),  L(t)が両方共1であれば、Wが完全にVに更新されてしまうことに注意しよう。
 \Theta(t),  L(t)の関数型は次のように与える。
 L(t) = L_0 \exp\left( -\frac{t}{\lambda} \right) \\
\Theta(\vec x, t) = \exp\left( -\frac{d^2}{2 \sigma^2(t)} \right)
学習の速度を決定するパラメータLは、時間とともに減少する関数である。 \lambdaは時定数である。
 \Thetaは更新するユニットが、どの程度BMUの近傍にいるかを表現している。dはユニットの位置 \vec xとBMUとの距離であり、d=0の時 \Theta =1である。dが大きくなるに従って、 \Thetaは減少する。
ここで \sigma(t)は典型的なBMUの近傍を定義する量であり、これも次式によって時間とともに減少するとする。
 \sigma (t) = \sigma_0 \exp\left( -\frac{t}{\lambda} \right)

結果

競合層として、20x20のユニットを用意し、ランダムな3次元ベクトルで初期化した。学習データとしては、ランダムに生成した3次元実ベクトル V \in [0,1)^3 を10000個用意した。
(なので、学習データの特徴が抽出されるというより、いかに分類されるかに興味を持って結果を見るべき)
学習パラメータは、 L_0=0.1, \lambda=10000/4=2500, \sigma_0 = 20/2=10とした。

3次元の実ベクトルは、RGB強度と解釈できるので、視覚的に学習を観察できる。学習前の競合層は以下の図のようであった。ユニット間の相関はないため、色がランダムに各マス目に配置されているのがわかる。
f:id:monopole:20150212003956p:plain
1万回の学習ステップを繰り返したあとの競合層は下図のようになった。隣り合うグリッドには似た色が並んでおり、うまく色分けできているように見える。
f:id:monopole:20150212003954p:plain
コンピュータはもともと、3次元の色ベクトルの意味を知っていたわけではない。(例えば(1,0,0)が赤である、とか。)ところが、いまやそれらの近いもの同士のマップを得たので、例えば赤とピンクの色コードを与えてやれば、それがどの程度近いのか、マップ上の距離で判定することができる(半教師なし学習)。また、与えた色コードから類似色を類推することも可能である。


最後に、学習過程をもう少し詳しく見る。10回目と20回目の更新後のマップの様子を下に並べた。
マップのランダム性は速やかに薄れていき、全体として同じような色が並んでいる。これは、学習過程の早い時期では、BMUを中心とした大きな円の内側で強い近傍学習が行われているためである。
f:id:monopole:20150212011525p:plain
f:id:monopole:20150212011537p:plain


次に50回めと90回めの更新後のマップを示す。
50回目の更新後のマップは、まだ全体として似たような色をしているが、少しずつ色分けの効果を見ることができる。90回目になるとその傾向がさらに顕著になる。
f:id:monopole:20150212011549p:plain
f:id:monopole:20150212011608p:plain


1000回目、2000回目の更新後のマップを以下に示す。学習パラメータが時間の減少関数であるため、学習はゆっくりしたものであるが、次第に最後のマップのように、マス目の間の色の区別がはっきりしていくのが見て取れる。
f:id:monopole:20150212011627p:plain
f:id:monopole:20150212011635p:plain

考察・課題・感想

  • 今回は1つのパラメータセットで実験したが、より良いパラメータセットはあるだろうか?
  • numpyの便利機能を使わず、forループのゴリ押しで書いたところを直して高速化する
  • 色の仕分け以外にも色々応用できそう。MNIST画像データではどうだろうか
  • 流行りのdeepなアーキテクチャにできるだろうか?
  • Pythonすごい、Numpyすごい
  • 神経科学的基板も勉強したい

pythonでプロットするときpylabは非推奨

まあ言いたいことはタイトルで尽きてるんだけど。

発端はMatplotlibとpyplot, pylabがどういう関係にあるのか気になって調べたこと。
よくあるpythonでのプロットの例ではpylabがインポートされてるが、
pylabはmatplotlibのラッパに過ぎないみたいなので、使うのが難しくないならmatplotlib.pyplotを
直接叩こうかと思って。

1.4.1.2. pylab
pylab は matplotlib のオブジェクト指向ライブラリに対する手続き的インターフェースを提供します。このモデルは Matlab™ をお手本にしています。

http://turbare.net/transl/scipy-lecture-notes/intro/matplotlib/matplotlib.html


で、ググったところ、matplotlib.orgのFAQにドンピシャのことが書いてあった。

Matplotlib, pyplot and pylab: how are they related?
Matplotlib is the whole package; matplotlib.pyplot is a module in matplotlib; and pylab is a module that gets installed alongside matplotlib.

Pyplot provides the state-machine interface to the underlying object-oriented plotting library. The state-machine implicitly and automatically creates figures and axes to achieve the desired plot.

(中略)

pylab is a convenience module that bulk imports matplotlib.pyplot (for plotting) and numpy (for mathematics and working with arrays) in a single name space. Although many examples use pylab, it is no longer recommended.

For non-interactive plotting it is suggested to use pyplot to create the figures and then the OO interface for plotting.

http://matplotlib.org/faq/usage_faq.html


まあ超訳すれば、プロットを静的に扱う限りはpyplotで十分で、あえてpylabを使う必要はないということらしい。

新iPhoneのディスプレイサイズについて

発表会直前なので自分の予想を書く。

初代の3.5インチディスプレイのiPhoneが出た時には、画面がでかすぎるから日本では売れないと言われたものである。
しかし今になってみれば、アンドロイドでは4インチ以上のディスプレイは当たり前であり、
iPhoneの画面は小さいと、パワーユーザだけでなく、比較的ライトユーザと思われる
人々からも購入を敬遠する理由として挙げられてしまっている。

そういうわけで、iPhoneのディスプレイサイズを大型化することが、アップルの
とるべき戦略として、ほとんど必然的な路線になってきている。
しかし、そこには(おそらく)アップルを悩ませる大きな2つの問題が存在する

  1. 片手操作を放棄して良いか否か
  2. アプリの解像度の互換性

まず1つ目の問題。
そもそも初代iPhoneのの3.5インチディスプレイは、片手でのホールド操作を考慮したサイズだった。
実際、iPhone5以降の4インチディスプレイでも、3.5インチ時代の横幅はキープしたままであった。
アップルはアンドロイドに対し、iPhoneの画面サイズは片手で操作できる最適なサイズであると謳って宣伝しており、
単純な画面の大型化はこの優位性を損なってしまうことになる。

2つ目の問題も、アップルがアンドロイドに対して優位性を誇っていた部分である。
iPhoneは画面の解像度が統一されているため、アプリのUIや絵をドットバイドットで用意することができ、
開発者は開発が簡単になるし、ユーザは美しいUIでアプリを楽しめるというわけだ。
iPhone3Gから4へのアップグレードでは、ディスプレイサイズこそ変わらないが、
解像度をなんと4倍の、326ppiという、当時としてはとんでもない高さに上げてきた。
ここで中途半端に解像度をあげるのではなく、一気に4倍も上げてきたのは、
それまでに公表されていいたアプリとの互換性のためである。
1ドットを4ドットに対応させることで、アプリ表示に変なギザギザなどが出ないように配慮したわけである。
さらにその二年後、iPhone5から4インチディスプレイに移行する時には、
ppiは同等で、ディスプレイの縦方向のピクセル数を増やすという対応に出た。
そして、3.5インチディスプレイに最適化されているアプリについては、
4インチディスプレイの上下に黒いバーを挿入することで、ドットバイドットの表現を保つ対策をした。
もういちいち書かないが、このドットバイドットのこだわりは、
iPadiPad retina displayモデル、iPad miniiPad mini, retina displayモデルのリリースの際にも現れている。
一方でアンドロイドはディスプレイサイズがバラバラなので、アプリ開発者が思った通りの表示をするのが難しい。
ユーザもギザギザしたアプリ体験をしてしまうかもしれない。
この点において、解像度が限られているiPhone製品では、開発者もユーザも
美しいUIの開発&体験が容易である、というのがiOS陣営の優位性であった。
もしも素朴に画面を大きくし、解像度を変えてしまえば、この優位性も危うくなる。
これが2番めの問題である。


さて、少し話題がそれるが、Galaxy noteが出たあたりから、私はファブレット(5~6インチ程度のディスプレイサイズ)には
一定の需要があると思っていた。
スマホの片手操作を諦めてしまえば、片手にフィットする3.5インチなんて気にする必要がないわけで、
両手操作を前提にすればディスプレイはまだまだ大きくできるのである。
現実的には、6インチ程度までなら、持ち歩くにはギリギリ大丈夫そうである。
そして画面は大きければ大きいほど、情報の視認性が良い。
これはiPhoneiPadを比べてもわかることだろう。
このファブレット事業には、アップルも乗り出す余地があると思った。


それを踏まえて、1年前、アップルがiPhone5sと同時にiPhone5cを発表した時、私はこう予想した;

  • アップルは今後、iPhoneを2製品のラインナップに分ける
  • 1つはエントリー向けモデルで、iPhone5cの後続品。ディスプレイサイズは4インチのまま
  • もう1つはパワーユーザ向けで、iOS搭載のファブレット。iPhone5sの後続機で、6インチ程度の新しい解像度のディスプレイを採用
  • ファブレットで旧iPhoneむけアプリを動作させるときは、iPadiPhoneアプリを動かす時のようにレターボックスを使用
  • ファブレットは片手で操作できるよう、ソフトウェアでの工夫がOSレベルで搭載される

最後の項目は、例えば画面全体に指が届かなくても、メニューなどをジェスチャ操作などで呼び出せる機能である。
画面の大型化と片手操作の両立は、ソフトウェアの改善で解決できると思う。
これが次期iOS8の隠し球機能になると予想した。


そして1年後の今日、すでにアップル新製品のリーク情報は出回っており、
新機種は2種あり、片方は4.7インチ、もう片方は5インチ超のディスプレイとのことである。
私の予想に対しては、4.7インチディスプレイモデルの方が意外である。
ここで新たに4.7インチディスプレイ向けの解像度を用意して、ただでさえ細分化される
iOS製品の解像度の種類を増やすとは思えない。
確かに今の4インチiPhoneだって、私の観測する限りでは、特にアジア人女性などは
両手で操作している事が多い。
どうせ両手で操作するなら、4インチよりも4.7インチのほうが視認性が良いということだろうか。
いろいろなソースから情報が来ていることから、ディスプレイサイズの情報はほぼ確定だと思う。
というわけで、私は次のiPhoneに次のような予想を立てる

  • 4.7インチiPhoneの解像度はiPhone5と変わらず、1136x640、したがって277ppi程度の解像度になる

すると、解像度がretinaの基準(たぶん)である300ppiを下回ってしまう。
なので、4.7インチモデルは廉価版の位置づけになるか、もしくはアップルお得意の開き直りで、
アプリ開発しやすいやろ!と自慢してくるかもしれない。

長くなったので私の予想を最後にもう一度まとめてエントリを閉じます。

  1. 5インチモデルiPhoneは新しい高い解像度。旧アプリはレターボックス表示
  2. 4.7インチモデルはiPhone5と同じ解像度
  3. iOS8には大画面iPhoneを片手で操作しやすくするような機能がOSレベルでサポートされる


以上、これからもiPhoneを片手で使いたい人の希望です。

都内で勉強会に使えそうな公共施設

公営で利用料が安くて、かつどこどこ区民限定みたいなのがない場所

大田区産業プラザPIO
http://www.pio-ota.net/

東京都立産業貿易センター
http://www.sanbo.metro.tokyo.jp/

BESOM3.0RCをUbuntu 12.04 LTSで動かした

参考:BESOMのダウンロードページ
https://staff.aist.go.jp/y-ichisugi/besom/download.html


https://staff.aist.go.jp/y-ichisugi/besom/besom3.0rc1/demo-manual30.pdf
このマニュアルに沿ってデモを動かしただけだが、記憶の整理のためにメモしておく。

まずzipファイルをダウンロードして適当な場所に展開する。
https://staff.aist.go.jp/y-ichisugi/besom/besom3.0rc1/besom3.0rc1.zip
ここでは

~/besom3.0rc1

に必要なファイルが展開されたとしよう。

ソースコードdosのフォーマット(改行コード)になってるので、まずそれを直す。
例えば、lab/Lab.java に関しては、

cp lab/Lab.java lab/Lab.java.original
nkf -uL lab/Lab.java.original > lab/Lab.java

などとして、UTF-8unixの改行コードのファイルに変換する。

あとは、「デモの動かし方」にあるように、MNISTのファイルを4つ取ってきて
適当なディレクトリに保存する。
そのパスを、image/Image.java, mnist/Mnist.java の中に書き込む。

コンパイルは、

javac lab/Lab.java

などと、すべてのjavaファイルに対して行う。

サンプルコードの起動は、

cd ~/besom3.0rc1
java lab.Lab

である。
(この辺のjavaの作法がわからずハマったので念のため。)

無事X上にアプリケーションのGUIが表示され、計算が走った。
f:id:monopole:20140530010350p:plain

問題はこれがどういうサンプルなのかをソースから紐解く所である・・・。