朝、日比谷線に乗ったら車内の電気がバババッと消えました。
そのあと急激に車両の速度が減衰して停車。車内がザワザワ。

何事かと思いましたが、社内アナウンスで停電と分かりました。安心。



5分くらい停車したあと動き出しました。

地下鉄が駅以外で止まると、災害のときに自分がどうなるか想像してしまいます。怖いなぁ。地下鉄。

停電の夜に

[Amazonで詳細を見る]

関連リンク

- 東京メトロ ホームページ
-- http://www.tokyometro.jp/index.html

最近は何故か、いろんな職業の人と話す機会に恵まれるようになりました。
そうすると言葉にならないけど感じることが多くなります。
今日は「上達に向けた努力」に関する考え方の工夫について、まとまったのでメモっておきます。

結論としては「上達に向けた努力の成果はアウトプットである。アウトプットされてれば質はともかく万事よし。」と考えよう、ということです。

アウトプットの質だけ見ると、解決方法がない辛さを感じるときがある

上達に向けた努力には様々な形があると思います。努力の成果を計る尺度の一つはアウトプットの量です。アウトプットの量が増えると、徐々にアウトプットの精度が上がり、独自性が増し、成果も沢山出て良いことだらけです。

上達に向けて努力しているときに、自分よりも上手な人のアウトプットを見て自分のアウトプットの貧弱さに打ちひしがれることが、個人的には多々あります。
打ちひしがれるのは楽ですし、いろいろ言い訳を考えて自分の貧弱さから目をそらすのも悪くはないのですが、数時間後に何も解決してないため、さらに愕然としたりします。

上達目的のアウトプットは質はさておき、量で評価しよう

最近、自分よりもある種のアウトプットが圧倒的に上手な人を沢山見て、他人のアウトプットを見てもショックを受けないことが大切ではないか、と思うようになりました。

ミスもOK。稚拙でもOK。好奇心を沢山もって、とにかくアウトプットする。そういう姿勢の人が個人的に素晴らしく見えます。

アウトプットの成果を自ら「アウトプットの質で評価する」とした場合、世の中には様々な上級者がいるので、いつどこから高品質なアウトプットをひっさげて目の前に現れるか分かりません。
自信をもって出力したものが一瞬で無価値になるようなことを繰り返すと、どんなに強靭な精神をもっていても折れてしまうものです。少なくとも僕は万策尽きた時点でボッキリと折れます。

他方、アウトプットの成果を自ら「アウトプットの量で評価する」とした場合、周りにどんな上級者がいようとも、それ自体はあまり関係ありません。
自分のアウトプットの質が自分で許せるラインに到達していなくても問題は起きていません。起きていないと考えます。
これでアウトプットする度に無力感に襲われる負の連鎖に落ちることもなく、明るく出力ができます。

上級者はアウトプットの量が多い

しかし、そのときに気がつくことは「上級者は圧倒的にアウトプットが多い」ということです。
アウトプットの量だけで見ても、上級者に勝てないことが多々あることに気がつきます。
上級者はアウトプットの精度が高いだけでなく、いつのまにかアウトプットの速度が速くなっており、同じ時間で大量にアウトプットできます。

しかし、そのようなアウトプットの量で負ける問題は努力で解決できます。出来ない場合もありますが、できる場合がかなり多いのでは。
小粒で良いからとにかくアウトプットし、寝る間を惜しんで出し続ければ、量で勝てる可能性はあります。
相手も人間なので風邪をひくこともあるし、用事もあるし、やる気が無い日もあるので、相手が完全に止まってる日ならちょっとやるだけでもアウトプットの量で負けません。

量での評価は自分との戦い

量で評価するようにすると、全ては自分の内側での自分との戦いになります。
子供のころにラジオ体操のスタンプを押してもらいましたが、あれも行くことに意義がありました。
上手にラジオ体操ができたか、とか、ちょっと遅刻したか、とか、そういうのは関係ありませんでした。
毎日一個ずつ「毎日えらいね」とスタンプを押してもらえました。
子供心にあのスタンプはとても達成感があったなと思い、何が良かったのか時々考えています。

では、どの程度アウトプットすることを自分に課すべきか、というと、たぶん自分が負けたくない人よりも多くアウトプットすれば良いのではないかと思います。
どういう人に負けたくないか、というと、職業でアウトプットしている人は素人には負けたくありませんね。
例えばレストランのシェフの1日に料理をつくる回数が専業主婦に毎日毎日負けていたら何か嫌です。
まぁ、そんなに急激に腕は衰えないと思いますが。

おわり

ということで、上達を円滑にするには「出力の量を増やし、出力の質には一旦目をつぶり量だけ見よう。量の目標はライバルを見つけてそれ以上に出力するようにしよう」と考えてはどうかな、と結論づけて、一旦終わります。眠い。

とある事情から、ずっと手元のVM上のgitで一元管理してるソースコード管理を、状況に応じて別のレポジトリで管理するように切り替えることにしました。

僕以外の人には、ほとんど関係のない話です。

以前からコードを外部のリポジトリで管理しても、手元に全部のコードが残るので問題は無いし、そもそも僕の書くコードを流用する奇特な人はそんなにいないと思うので問題なさげ、と思っていました。
でも、手元のVMで管理が間に合ってるため外部公開とか面倒くさいし、CodeReposも最近は全然使ってないし、僕のコードは万人が頻繁に使う公共性の高いものではないのでユーザも居ないし、あんまり気持ちよく感じないなと思ってました。

今回の件は @mamoruk さんから、かなり背中を押されてやっとやり始めました。感謝。やりはじめると不思議と手が動きます。

状況に応じて管理方法を分けることにした

ソースコードは公開して平気なコードから、公開したら絶対駄目なコードまでいろいろあるので、自分でコントロールする必要があるコードはよりプライベートなgitレポジトリで管理することにした。

レポジトリ	管理するコード
github	公開して大丈夫で、とくにパッケージにもなってないコード
レンタルサーバ上のgit	公に公開できないけど、知人に見せたいコード
手元のVM上のgit	絶対公開できないコード
自分のサイトかGoogle Code	アプリケーションがまとまったらパケ化して上げておく

アプリケーションについてはアプリケーションごとにWIkiやトップページが欲しいので、自分のサイトで管理するかGoogle Codeで管理しようと思う。
多分、僕のサイト上に置いてあるよりもGoogle Code上にあった方が嬉しい人が多そう。

github の用意

実は github にアカウントを持ってなかったのでアカウント作りからやった。
自分のまとまってないコードを積極的に開示する状況に陥ることは予測してなかった。



アカウントを作ったあとは、以下のように作業をした。

- overlast's private - GitHub
-- http://github.com/overlast/private

Global setup:
 Download and install Git
  git config --global user.name "Your Name"
  git config --global user.email メールアドレス
  Add your public key
        
Next steps:
  mkdir private
  cd private
  git init
  touch README
  git add README
  git commit -m 'first commit'
  git remote add origin git@github.com:overlast/private.git
  git push origin master
      
Existing Git Repo?
  cd existing_git_repo
  git remote add origin git@github.com:overlast/private.git
  git push origin master

push するために追加する必要があるSSH の public キーは ssh-rsa だと怒られたけど、ssh-dss だと怒られなかった。

今後は dotfile など毒にも薬にもならないコードから順にアップしていく。

レンタルサーバ上に git をインストール

さくらのレンタルサーバにgitをインストールしてレポジトリを作った。
サーバの容量の上限が10GByteになったので、やろうと思えば、手元のコードは全部レンタルサーバでも管理できる。

さくらのレンタルサーバにgitをインストール

さくらのレンタルサーバに git の一番新しそうなのをインストール。
今日の段階では 1.7.1 っぽかったので、これをインストール。

実は自分の環境では、gmak中にエラーが起きた。

- @さくら

$ mkdir ~/src
$ cd src
$ wget http://kernel.org/pub/software/scm/git/git-1.7.1.tar.gz
$ tar xfvz ./git-1.7.1.tar.gz 
$ cd git-1.7.1
$ mkdir $HOME/local
$ ./configure --prefix=$HOME/local 
$ gmake 
(中略)
    SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/home/overlast'
Only one of PREFIX or INSTALL_BASE can be given.  Not both.
gmake[1]: *** [perl.mak] エラー 255
gmake: *** [perl/perl.mak] エラー 2

たぶん、perlbrewを使っているからかな。
このエラーはINSTALL_BASEを指定して、perlbrewでprel5なモジュールが入るディレクトリを指定すれば解決できる。
あと、このperlモジュールをインストールするときに、manを/share以下にインストールしようとするので、それをローカルフォルダに入れてくれるようにSITEPREFIXも指定。

別途perlモジュールをコンパイルして、続きをgmake。

- @さくら

$ cd perl
$ perl ./Makefile.PL SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ cd ../
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5 install

.bashrcのPATHに「$HOME/local/bin」を追加して、source ~/.bashrc。

あとは、--bareをつけてinitする。付けないとpushできない。

- @さくら

$ cd $HOME
$ mkdir repos.git
$ cd repos.git
$ git init --bare
Initialized empty Git repository in /home/you/repos.git/

これでローカルからpushするリポジトリはできた。

bareなリポジトリはデータ格納場所なので開発はできない。
cloneして、そこで開発する。まっさらだったら手元のgitリポジトリをadd & pushする。

まずは、ローカルなPC上にディレクトリを作ってgit initしてcommitしてみる。

- @ローカル

$ mkdir repos
$ cd repos
$ echo "This is my git repository" >> README
$ git init
Initialized empty Git repository in /home/you/repos/.git/
$ git add README
$ git commit -m "first commit"
[master (you-commit) 8d0baee] first commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README

今度は、これをレンタルサーバ上のリポジトリに突っ込んでみる。
SSHでpushするとレンタルサーバ上のgit-receive-packを見つけられないので、receive-packオプションでgit-receive-packの絶対パスを与える。

- @ローカル/repos

$ git remote add origin ssh://you@you.sakura.ne.jp/home/you/repos.git
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
Counting objects: 3, done.
Writing objects: 100% (3/3), 231 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://you@you.sakura.ne.jp/home/you/repos.git
 * [new branch]      master -> master

問題無いので、再度READMEを編集してadd、commitして、pushする。

- @ローカル/repos

$ echo "I'm very sleepy" >> README
$ git add README
$ git commit -m "second commit"
[master 8044db5] second commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ 再びpush
うまくいった

うまくいく。

つぎは今度は自分のPCの別のディレクトリでcloneする。
レンタルサーバの$HOME/local以下にgitをインストールしたので、SSHでアクセスするとパスが通っていないことになる。
なので、--upload-packオプションでgit-upload-packの絶対パスを与える。

cloneしたら3回目のコミットをclone先でやってpushもしてみる。

- @ローカル/repos

$ cd ../
$ mkdir repostest 
$ cd repostest
$ git clone ssh://you@you.sakura.ne.jp/home/you/repos.git repos --upload-pack /home/you/local/bin/git-upload-pack
Initialized empty Git repository in /home/you/repostest/repos/.git/
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
Receiving objects: 100% (6/6), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
$ cd repos
$ ls
README
$ less README
This is my git repository
I'm very sleepy
$ echo "I'm hungry" >> README
$ less README
This is my git repository
I'm very sleepy
I'm hungry
$ git add README
$ git commit -m "third commit"
[master e4fb5a1] third commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
うまくいった

うまくいった。
今度は、最初に作ったreposを更新する。

- @ローカル/repostest

$ cd ../../repos
$ git merge origin/master
Updating 68abac3..e4fb5a1
Fast-forward
 README |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
$ less ./README
This is my git repository
I'm very sleepy
I'm hungry

どうやら大丈夫。
clone、push、mergeが動いているので、多分なんとかなるはず。

ローカルで何かミスったら「git reset --hard ORIG_HEAD」すれば、直前のcommitに戻れる。

こっちでは活発な開発をおこなって、ある程度まとまったら知人にお試し公開する場所にする。

関連リンク

- GitHub
-- https://github.com/

ハマったのでメモ。

結論：後でとくに問題が起きないなら sufary.h を編集して SA_INDEX 型を int 型にすれば良い。

SUFARY の mkary で作れない索引を作る方法

SUFARY 付属の mkary を使うと「ファイルの全ての文字の位置」か「行頭の位置」を索引付けするなら簡単に array ファイル（SUFARY の索引ファイル）を作れる。

他方、各行の一部について部分に含まれる各文字ごとに索引付けしたい（例、CSVファイルの第Nカラムだけ索引付け）場合には、任意の部分の文字位置のポインタをバイナリで吐き出して 、最後に「mkary -so」することが多い。（-so を使うとソートだけ）

そうすることで、欲しい部分については柔軟に検索でき、不要な部分が検索結果に含まれなり、必要最低限のサイズの array ファイルを作ることができる。タスクによってはこのような索引付け方法が必須な場合がある。

このとき、バイナリはビッグエンディアンで出力する必要がある。
出力するバイナリのビット長は SUFARY のヘッダファイルである sufary.h において typedef されている SA_INDEX の型に依存する。

SA_INDEX の型が long だとハマる

sufary.h の SA_INDEX の型が標準だと long 型。

long 型のサイズは OS ごとに異なるが、手元の環境では 32bit long 型は4byteで、64bit long 型は 8byte だった。
もしも long 型のサイズが8byteなときに、4byte 長のビッグエンディアンなバイナリを mkary に入力すると、ソートできなくてSegment Faultする。

そのため特殊な array ファイルを作る際にバイナリを吐き出すプログラムは、環境ごとに異なる long 型のサイズに対応する必要がある。

SUFARY を 64bit OS 上でインストールする際はヘッダファイルを編集

とはいえ、環境ごとにことなる動作をする index 作成スクリプトはちょっと面倒くさい。
またプログラミング言語によっては 8byte 長のビッグエンディアンであるバイナリを出力するのが面倒くさい場合がある。

そもそも SA_INDEX の型が long で定義されているからややこしいことになる。
SA_INDEX の型が int でも、SUFARY を後で問題がとくに考えられない使い方しかしない場合には問題ない。

32bit OS上ののSUFARYでは索引づけできなくて、64bit OS上のSUFARYでは索引付けできるデータを扱うときだけ問題が起きる。
しかし、そのようなサイズのデータはそもそも接尾辞配列でindexするべきでは無いか、接尾辞配列の分散indexをつくるかすれば良い。

ということで、SUFARYの圧縮ファイルの lib/sufary.hを以下のように変更してからインストールする。

- sufary.h

- typedef long SA_INDEX;
+ typedef int SA_INDEX;

これでバイナリを出力するプログラムは 4byte 長のビッグエンディアンなバイナリを出力するようにするだけで、だいたいの環境で「mkary -so」できるようになる。

@echizen_tm さんに相談したら彼が過去に体験済みな問題で解決方法を教わった。ありがとうございます。

関連リンク

- SUFARY 臨時復旧ページ
-- http://nais.to/~yto/tools/sufary/

テアトルエコー前の渋谷川のあたりを歩いていたら、上流から短冊が流れてきました。七夕の短冊ですね。



現代でも短冊を都会の川に流す人はいるんだなー。驚いた。

驚きすぎて写真が撮れなかったので、早足でより下流側の駒沢通りまで歩いて再び渋谷川を覗き込みました。お、追いついた。



あの短冊、なんて書いてあるのかな？？



うーん、読めませんね。残念。

本当は、短冊に水で自然分解されにくい紙を使っている場合には、短冊流しをしちゃいけないと思います。
分解されない場合は露骨に残るゴミになるから、河川の清掃員の仕事が増えて、税金が無駄遣いされることになります。

近年は短冊を流すのではなく、燃やして、思いを天に届けようとするのが主流みたいなので、来年は燃やしてみて下さい。

関連リンク

- 渋谷川 - Wikipedia
-- http://ja.wikipedia.org/wiki/%E6%B8%8B%E8%B0%B7%E5%B7%9D

高村大也さんによる自然言語処理・機械学習の新定番本「言語処理のための機械学習入門」が発売されました。

言語処理のための機械学習入門

[Amazonで詳細を見る]

Amazonや楽天でも在庫が次々に掃けているようで、今日のところは売り切れの書店が続出みたいです。
この種の参考書に飢えている人が少なからずいる、ということですね。

ネットでは確かに売っていたのですが、筆者の高村さん自身が「今月か来月に発売なんだけど、よく分かってない」ということ（そんなことがあるのww？？）みたいなので、どんな感じかな、と、新宿の書店に行ってきました！

おおお、ありました！
ちゃんと入荷してます。神々しいです。



私と @echizen_tm さんと @uchumik さんの 3 人で買いに行きましたが、ちゃんと一人一冊ゲットできました。
買う前にパラパラとめくって読みましたが安いですよね。この本。2940 円とかありえません。

この教科書を研究室の勉強会などで使う場合には「最初に6章を読んで、その後2章以降を読みつつ、分からなくなったら1章を参照する」みたいな読み方の人もいるかな。
1章は本書で使う数学の基礎知識について解説する章で、結構なページ数があるから、飛ばす人はバッサリ飛ばしそう。

特筆すべきこととしては「'言語処理のための機械学習入門」は章末問題も充実しており、おまけに、章末問題の解答もあるんです。
信じられますか？　はい。
それにしても、この手の教科書にしては優しい対応ですね。
アルゴリズムデザインとか解答が無いから時々涙で前が見えません。

そういえば、「言語処理のための機械学習入門」を買いに行ったら「計算機シミュレーションのための確率分布乱数生成法」という大変興味深いタイトルの本が出版されていました。


計算機シミュレーションのための確率分布乱数生成法

[Amazonで詳細を見る]

パラパラめくると非常に濃い内容で、式の展開が丁寧だし、疑似コードも充実。
濃すぎるので、どれだけ売れるのかちょっと分からない本ですが、立ち読みレベルの判断では良書。
この本も一家に一冊的な書の予感。買わなきゃ。

ああ、横道にそれました。

高村さん、出版おめでとうございます。よかったよかった。

書籍の情報

- コロナ社｜書籍詳細｜機械学習入門
-- http://www.coronasha.co.jp/np/detail.do?goods_id=2728

自然言語処理シリーズ 1
言語処理のための 機械学習入門	

東工大教授 工博 奥村学 監修
東工大准教授 博士（工学） 高村大也 著

判　型：A5
予定ページ：224頁
ISBN：978-4-339-02751-8
予定価格：2,800円

自然言語処理における機械学習の利用について理解するため，
その基礎的な考え方を伝えることを目的としている。
広大な同分野の中から厳選された必須知識が記述されており，
論文や解説書を手に取る前にぜひ目を通したい一冊である。

関連する記事

- 「言語処理のための機械学習入門」が近日発売

ネットで買う

言語処理のための機械学習入門

[Amazonで詳細を見る]

▼楽天で「言語処理のための機械学習入門」を調べる。
計算機シミュレーションのための確率分布乱数生成法

[Amazonで詳細を見る]

関連リンク

- Hiroya's homepage
-- http://www.lr.pi.titech.ac.jp/~takamura/index_j.html
- 奥村研究室ホームページ
-- http://www.lr.pi.titech.ac.jp/

またやろうポスターの新作が出てました。
今度は荷物が邪魔になっていたので前に抱える男性。



混んでる電車で本を読むのはいかがなものか、と思いますが、思いやりが大切だと主張したいポスターなので問題なし。

実際には荷物を背負っているよりも前に抱えた方が邪魔な場合もあるので、状況に応じて荷物を持ちましょうということですね。

関連リンク

- 東京メトロ：マナーポスター
-- http://www.tokyometro.jp/anshin/kaiteki/poster/index.html

炎天下に40分も並んで日本武道館へ。

行列の裁き方が悪過ぎて各所でスループットが落ちまくり。
もっと若者を信用したほうが良いと思いました。


# 他の写真はこの写真の前後にあります。

あまりの熱さと待ち時間のため中に入って席に座るだけで、ヘトヘトになりました。

ちなみに参加したイベントは、まるでサイゼリヤのハンバーグの味みたいでした。

夏の武道館に行くときは、自販機があんまり無いのでお菓子と飲み物を忘れずに。

関係リンク

- 財団法人 日本武道館
-- http://www.nipponbudokan.or.jp/
- [を] 武道館で社員大会
-- http://chalow.net/2010-07-06-1.html

「第43回情報科学若手の会」の参加申込が始まっています。締め切りは7月31日まで。
満員になった場合も締め切りになるそうです。

- 情報科学若手の会 | 第43回情報科学若手の会
-- http://wakate.prosym.jp/2010/log/eid10.html

この会は参加すると良い刺激を受けるので、是非参加することをオススメします。
あと今回は高木浩光先生の招待講演もあるそうです。ワクワクしてきますね。

僕は去年開催された「第42回情報科学若手の会」に参加しました。
ですが、そのときの日記が公開状態になっていないようです。
どうやら、そのころの僕の情報の入出力バランスは最悪だったことが推測できます。
そのような時期に参加したので、参加したことで強い刺激をうけて直後に頑張れた記憶があります。

僕は「今年も参加しようかな。でも僕も若手なのかな。まぁ、でも自然言語処理研究者若手の会（YANS懇）とか僕の先輩も参加してるし大丈夫か。いやいや、、、。」などと、参加するか、しないか、迷っている状態です。

小町さんもブログの記事で言及していますが、ちょうどNLP若手の会とかぶらないで開催される（情報科学は11・12・13で、NLPは14・15・16）ので、この週は充電期間ということにしてこの週まで頑張ることにしようかな。 とても忙しいはずな時期なので、もうちょっと考えてみます。

渋谷の西武デパートの入り口で「つぶやきスター祭り」というイベントをやっていました。
具体的には笹の葉に短冊をつけるイベントでした。



僕も1枚短冊を書きました。
短冊は7月7日を過ぎたら東京大神宮に奉納されるのだとか。

願いが叶うといいなぁ。

RSSフィードの各記事ごとに tweetmeme のボタンをつけてみました。



- TweetMeme Button | Tweetmeme Help
-- http://help.tweetmeme.com/category/button/

ブログの個別エントリには topsy のボタンを付けているのですが、 tweetmeme とどっちが良いのかなぁと思ったので、RSSフィードに入れて試してみることにしました。

僕自身が今までそんなに自分のブログの Retweet ボタンを押してなかったので 0 が出まくってますね。。。

関連リンク

- TweetMeme - Search and Retweet the Hottest Stories on Twitter
-- http://tweetmeme.com/

- Topsy - A search engine powered by tweets
-- http://topsy.com/

関連エントリ

- [O] ブログに「Topsy」の Twitter ボタンを設置しました
-- http://diary.overlasting.net/2010-05-04-4.html

有楽町イトシアの地下で借りぐらしのアリエッティのポスターを見かけました。
こんなに引き延ばしても大丈夫な絵ってすごいなぁ。。



と思ったけど、よく考えると映画館のスクリーンで見るんだから、この位の大きさ大丈夫ですね。

そういえば前売り券を買おうと思っていたのを、この記事を書いていて思い出しました。週末に行こうかな。

借りぐらしのアリエッティ サウンドトラック

[Amazonで詳細を見る]

床下の小人たち (岩波少年文庫)

[Amazonで詳細を見る]

関連リンク

- 借りぐらしのアリエッティ 公式サイト
-- http://www.karigurashi.jp/index.html

日本語に対応した光学文字認識(OCR)を実現する nhocr を CentOS にインストールしてサンプルを実行するところまで作業しました。

nhocr とこれに関連する必須なライブラリ

- nhocr
-- http://code.google.com/p/nhocr/

- O2-tools
-- http://www.imglab.org/p/O2/

- FreeType2
-- http://www.freetype.org/
# http://freetype.sourceforge.net/dounload.html で Stable Releases で示されている最新のパッケージを使う

インストール

O2-tools と FreeType2 のインストール

O2-tools 2.00 と、FreeType 2.3.12 をインストールする。
両方ともダウンロードしたtar.gzなパッケージをtar xfvz で解凍して、

./configure --prefix=/usr/local
make
make (check|test)
sudo make install

するだけ。大変に簡単。
標準のインストール先は O2-tools が何故か ${home}/O2 以下で、FreeType は /usr/local 以下なので、configure の prefixでインストール先を指定する必要があります。

nhocr-0.20 の libnhocr/nhrec.cpp を編集

nhocr-0.20 の libnhocr/nhrec.cpp で宣言されている NHrec::rec_line(3) 関数には CharBox ポインタ型の変数 cblist が宣言されています。
この cblist は内部で初期化されて以降、どこでも使われないのですが、最期に以下のようにして delete しようとしています。

if (cblist) delete_cblist(cblist);

おまけに、この delete_cblist(1) 関数は ./libnhocr/segchar_adhoc.h では宣言されているされているけれど、./libnhocr/segchar_adhoc.cpp には実体が書かれていないので make 中にリンクエラーが起きます。

なので、サクッと以下のようにコメントアウトしました。

// if (cblist) delete_cblist(cblist);

他のどこかでメモリリークしてしまうかもしれなさそうだな、と軽く不安になりますが、とにかく動かしてみます。

nhocr-0.20 のインストール

準備はできたので nhocr-0.20 をインストールします。

./configure --prefix=/usr/local CXXFLAGS="-I/usr/local/include/freetype2/"
make 
make (check|test)
sudo make install

サンプルを実行

サンプルの実行は test ディレクトリに移動して run-test を実行します。

$ cd test
$./run-test
fs.pgm: ファイルシステム
hello.pgm: ニんにちわ
（以下略）

無事にこんにちわ画像が「ニんにちわ」になりました。味わい深いですね。

この後どうするか。

サンプルが動いたし、この次はサンプル以外の任意の画像中の日本語文字を認識しています。
ですが、実は nhocr 用の画像は OpenCV を使って作るのでプログラムを書く前に OpenCV もインストールする必要ありです。
面倒くさい。

結局、何がしたいの？

今後、画像中の日本語と英語の両方を上手に認識させてみたいと思ってます。
OCRの日本語向けモデルは英語の文字認識精度が低く、英語モデルは日本語の文字認識に弱いです。
単純には日本語と英語の両方で合計2回認識処理をして結果をマージして使えばいいのかな。

夜、家に帰る途中で気がついたのですが、僕は分からないことがあると調べる癖があります。
多分、分かったときに凄く気持ちが良いから、ついつい調べてしまうのだと思います。

分からないことを調べるのは悪くない、と思うかも知れませんけれど、僕自身はこの癖にちょっと困っています。

なぜなら、分からないことが調べても分からなかったときに堪え難いストレスを感じるのです。
どのくらいストレスかというと、脳が逃避行動を起こして寝てしまうほどです。寝なくても体が重くてグッタリします。

分からないことが分からない原因は、いろいろあります。
例えば、情報を解析するには実力不足である場合、そもそも情報を辿るための情報が無い場合、誰かが意図的に情報を隠している場合、誰かが見え透いた嘘をつき真実を言っていない場合、などいろいろです。

実際に分からないことに直面すると、本当に調べて分かることなのかを横においておいて、調べることに没頭してしまいます。
そして分かった場合は爽快な思いをし、分からなかった場合はグッタリします。
おまけに何かをやっているときに分からないことがあると、しばしば調べもので脱線してしまい、我に返ったときに後悔します。

こんなふうに無意識で分からないことを調べてしまう癖は、ちょっと工夫することで勉強に利用できそうです。
例えば必須な調査が捗らない場合に、その調査の対象を意識的に「調べるべき謎」として捉え直せば良いのではないでしょうか。

自分の癖を使って自分を伸ばそうとしたことが無かったので、勉強にうまく活用できるのか分かりませんが、自分の直せない癖とは何とか上手につきあっていきたいものです。

六本木の鳥は人に慣れ過ぎです。

たとえば雀。椅子に座って休んでいると足下の間近まで餌が無いかやってきます。



こんなに雀の近くにいるのは自宅の庭でも無理。
六本木生まれ六本木育ちなのかな？

鳩はくつろぎすぎて道ばたで座ってウトウトしたりします。



僕も道ばたでゴロゴロしたいわ。

CentOS 4.8 上で「perlbrew install 任意のバージョンのPerl」を実行したら、コンパイルエラーでインストールできなくなっていました。

perlbrew は任意のバージョンのperlを$HOME（自分のホームディレクトリ）以下にインストールするためのアプリケーションです。
レンタルサーバや研究室など複数人で計算機を共有する場合に、他人に影響を与えずに任意のバージョンの Perl をインストールできるので重宝します。

perlbrew のインストール方法をについては『「perlbrew」と「cpanminus」と「local::lib」を使って、さくらのレンタルサーバで任意のバージョンのPerlを使う』 [2010-04-24-1] という記事に書きました。

さて、本題に戻ってログを見てみると、ざっと以下のようになっていました。

$ tail -f $HOME/perl5/perlbrew/build.log
（中略）
IO.xs: In function `XS_IO__Poll__poll`:
IO.xs:249: error: Invalid application of `sizeof` to incomplete `pollfd`
（省略）

このようなエラーが出ているためインストール時にエラーが出た Perl のソースを grep してみたところ、/usr/include/poll.h と /usr/include/sys/poll.h をチェックしているようです。で、存在していたら優先的に include される前者の /usr/include/poll.h が不具合の原因かもしれないと思い、ファイル名を変更したところ、perlbrew install できました。force オプションは付けなかったので sys/poll.h が include されて IO.xs から成生された IO.c を正常にコンパイルできたのでしょう。

なんで、include/poll.h は駄目で、include/sys/poll.h が大丈夫なのかは深追いしてない分かりませんが、検索エンジンで検索しても同じエラーが出た起きていることを書いている人が1人しか見つからないので、非常に稀な問題でハマってるのかも。。。
素直に CentOS 5.x 系を使っていれば起きない問題なのかもしれませんね。

「卵が先であるべきか」または「にわとりが先であるべきか」という問題は多くの場合に結論が得られないものです。

あなたは養鶏場の職員だとしましょう。素晴らしい孵卵器を開発でき、養鶏に関わるノウハウを充分もっているとします。

卵とニワトリを効率良く手に入れて養鶏場を繁栄させたい場合、状況に応じて自分が楽に入手できる方から入手すれば良いと思いますし、そのほうが最終的な結果は得やすいと思います。

あなたが気まぐれなオーナーのいる養鶏場で働いているときに、オーナーから「新しい養鶏場をゼロから繁栄させてくれ。でも、にわとりを先にもって来てくれないと最初の卵はあげられない」と言われてしまう状況があったとしましょう。

このような場合、あなたがどれだけ素晴らしい孵卵器を開発したとしても、どれほど養鶏に関わるノウハウをもっていても、そもそも卵を手に入れることが完了していないので、永遠にニワトリ生誕 & 養鶏場の繁栄には至りません。
どうしても卵が欲しい状況にある場合は、ニワトリを意地でも捕まえてくるか、買ってくるか、なんとか無理矢理なんとかするか、、する必要があります。

その結果、あなたは運良く良い感じのニワトリをゲットできたとしましょう。

だいたいニワトリを手に入れる前や手に入れる過程で気がつくことなのですが、ニワトリを手に入れてしまうと「もうオーナーから卵をもらう必要ない」ような場合も多そうです。

それを見たオーナーは「なるほど、もう卵はいらなさそうですね。運が良いですね。はっはー。」などと言うかもしれません。
ニワトリを無理なく手に入れることができたのなら、そのオーナーの言葉を聞いても笑っていられるでしょう。

逆にニワトリ（現実にはニワトリ以外のものを指すので入手にはコストがかかります）を手に入れるために多大な犠牲を払っていた場合、オーナーの笑いを聞いた瞬間ブチ切れずにはいられないと思うんです。
「おまえが最初に卵（現実にはニワトリを効率良く得るためのリソースを指します）をくれれば全部丸く収まったんだよ！」などと。

こういう茶番は自分が当時者になるとなかなか笑えないものです。

今日は久々にダラダラとした週末。
用事のために横浜へ移動したあと、ボーっと椅子に座って考え事。

こういうボーっとする時間があると無意識で考えていることがまとまるので、とても大切。

今日は週末なのに朝起きられたので頭の中を整頓する作業をしていました。
こういう時間を持てたのは久々。嬉しい。

あんまりうまくまとまらなかったけど、自分の考えていることは既に分かっていることをヒントに考えてるうちにまとまってくるので、地道にやり続けるしか無いです。

今日は午後からバタバタするので10時くらいまではノンビリしようかな。

ソフトウェアを作るときに、作ったものがその後どう使われるかを意識することはとても大切だ、と僕は思います。
なぜなら、誰かに使ってもらえるものを作った時にしか分からないことが多くて、分かること自体が自分の財産になると思っているからです。

自分が作ったものを使ってもらうためには、作ったものの営業、宣伝広告の作成やデモ作成や導入サポート、コンサルなどの業務も欠かせません。

使ってもらおうとしている技術が求められているもので、それなりの性能をもっていて、導入が簡単なら使ってもらうまでの時間は短くて済みます。
他方、旬を過ぎていたり、性能が低かったり、導入コストが高い場合にはいくら押しても使ってもらえる日は（なかなか）来ません。

現実的な解決策は、細かく作業時間を見直して「調査・実装以外の作業量が実装より増える前に次のネタを探す」ことだと思います。

固有の課題だけではなく周辺領域を見回しつつ、新しい技術・知見を取り入れ、競合を分析し、すこし先を考えてものをつくれば、実装と普及しやすさを調度良いバランスで実現できると思います。
その結果、 実装以外の作業量が増えすぎることを防げるのではないか、と思います。眠い。