日記 - 2013-03
2013-03-28
人工知能プロジェクト
先週の追いコンで@slope81に煽られた（というと聞こえが悪いけど，色々質問されて知識不足を感じた）ので， 去年やろうとして途中でなあなあになってしまった人工知能の勉強を再開しています． まあこうやって定期的に刺激されるのはモチベ源になるしありがたい事ですね……．
自分が興味を持っているのはいわゆる「強いAI」のほうで，要するに人の意識をいかにして構成するかという話なのですが， この表現からも分かるように哲学的な側面があるかなり大きい問題なので，なかなか1歩を踏み出すのが難しいところがあります． 実際去年の途中でプロジェクトが止まってしまったのは，あまりに理想が巨大すぎて何から手を付ければよいか分からなくなったという面もあります．
幸い今は卒論を終えて色々見えてきたものがあり，とりあえず小目標を立てて実装してみるというのがステップとしてもモチベ維持策としても有効であると思うので， 何かしら動く形にするために必要な情報を集めている段階です． まずは既存の研究を調べて，どのような形のAIなら小目標として納得できるかですね……．
と，そんなことを考えつつ今週は「脳の中の幽霊」を読んでいました． 読書メーターで書いた書評 ．
人工知能ではなく，人間の意識とはなんぞやという哲学的な方向の本ですが，実験的な視点から書かれているので非常に読みやすいです． 哲学というと科学と対立する概念のように考える人もそれなりにいるようですが，科学も結局は考え方の1つでしかないので哲学の一種には違いありません． 特に知能のような分野に関しては，そもそも境界が曖昧な気もします．
2013-03-18
滋賀・福井旅行
先週火曜から土曜にかけて，滋賀・福井あたりをぶらぶらしてきました． 旅行記 ．
本来の目的は福井でボルガライスを食べることでしたが，最終的に一番収穫だったのは豊郷巡礼でした．
2013-03-06
NaN ≠ NaN
Codeforces #146(Div.2)のABCを解いた(昨日の話)．
3/1に，謎の求人として 来栖川電算のアルバイト募集 がTwitterで話題になりました． 謎というのは求人に書いてあった問題で，
(1)JavaやC#で「while(i != i);」を無限ループとするiを宣言してください。←この問題を見てピンときたらご応募ください！
というものです．
この問題の答えは NaN なのですが，意外と NaN != NaN
が真であるということを知らない人も多く，
また確かに言われて見ると厳密な定義は自分も知らなかったので，調べてみました．
参考資料はもちろん IEEE754 です． IEEEは大学単位の契約があるため，大学の回線を使えば読み放題なのでありがたいですね．
問題となるのは5.11節， “Details of comparison predicates” です． まず，この節の2段落目を見ると，2つの浮動小数点数間の関係は4通りあり，それぞれ less than，*equal*，*greater than*，*unordered* ということになっています． ここで unordered というのは NaN が比較に絡んだ時の関係で，オペランドの片方が NaN であればもう一方の値に関わらず関係は unordered となります． 両方とも NaN のときも unordered です．
次に4段落目と表5.1 - 5.3で，2つの浮動小数点数間での関係演算が22種類挙げられており，それぞれについて4通りの関係のうちどれを真とする演算かが定められています． これらは基本となる11種類の演算とその否定で，11種類の内訳は Equal，*Greater*，*GreaterEqual*，*Less*，*LessEqual* の5つについて Signaling NaN が絡んだ時に例外を飛ばす版と飛ばさない版の10通りに加えて， Unordered (これは必ず例外を飛ばさない) となっています．
これらの表には，古くから使われてきた演算子や名称について，それぞれどの演算を割り当てるのが適切か示されています．
これによれば，等号とその否定はそれぞれ compareQuietEqual と
compareQuietNotEqual に割り当てることになっており， さらに
compareQuietNotEqual は unordered に対して真になるとされています．
すなわち NaN 同士を != で比較すると，Signaling
NaNであっても通常は例外が飛ぶことなく真になるということです．
2013-03-01
研究あれこれ
2/28, 3/1と画像電子学会の研究会に行って発表して来ました． とりあえず発表して思ったことと，あとついでに研究の進め方について前に考えたことを書いておきます．
タスクは出来る限り細分化する
タスクを大きめの塊にしておいて，塊単位で消化していくのは楽だしある種直感的ではあるけど， やる気の出ない日やミスが見つかって何をすればいいか見通しが立たなくなったときに作業が進まないという問題があります．
これを防ぐためにはタスクをなるべく細分化しておき，やる気がなくても方針変更を迫られても，ちょっとずつタスクを消化できるようにすると良いです． タスクの分割は時間を食われるし面倒だけど，構成の整理にも繋がるし，長い目で見ると得になります． いわゆるチケット駆動開発にも通じるところがあります．
初見の印象を覚えておく
論文でも発表でも，受け手は普通は初見でアイデアに触れます． 一方で論文を書いている/資料を作っている本人はそのアイデアについて文字通り四六時中考えており，ほぼ飽和していると言って良い状態です． するとどうなるか． 書き手は色々な事象や前提を自明のものとして省略してしまいますが，読み手はそれらの知識がないため，伝えたいキーアイデアがうまく伝わらなくなります．
これを防ぐためには初見の人に見てもらい，指摘を受けるのが一番良いと思います． が，いつもこの手法が使えるとは限らないし，2回目以降はある程度内容が理解されてしまうので，だんだん書き手寄りになってしまう可能性があります．
そこで使えるのが，自分が最初に論文を読んだ時の第一印象です． 研究に使った論文を読んだ時，それは当然初見なので，そこで説明されている手法に対して様々な疑問が出るはずです． これらを忘れないようにメモしておき，自分で論文を書く時にはそこに書いてあることを押さえるようにすれば，初見でもわかりやすいものになるのではないかと思います．