人間のように学習し思考する機械

Building Machines That Learn and Think Like People
という論文がarXivに上がっている。

アブストラクトしか読んでいないが、果たしてここに書かれているような
　(a)理屈や理解をサポートするようなcausal modelを構築すること
　(b)物理学や心理学の基礎を学ぶこと
は重要なのだろうか。
(a)は単なるパターン認識ではなく、理屈があることの方がよいという
前提の基に提案されているが、それは人間の都合なのでは。
(b)に関しても、理由や理論はすべて単なるモデル化に過ぎないのだから、
人間が構築したものを新しい知能に押し付けることがよいことなのかは疑問だ。

結局、できあがった人工知能がブラックボックスになっては、毒にも薬にも
ならないという思いが強いのだろう。むしろ、毒にはなっても薬にはならない
という被害妄想が強い気がする。
実際には、自然と同じように、恩恵も災害ももたらすような、毒でも薬でも
あるようなもの、というのがイメージには合う。
自然と同じでは結局現状と変わらないと思うかもしれないが、低コストで高サイクルに
経験を積めるというのは、理屈を構築するにあたっては重要な違いだ。

人間と同じような意識を実装したいのであれば、この論文のような方向性は
ありかもしれないが、果たして意識を手に入れたいのだろうか。

自然災害

高度に進化した人工知能は理由による追跡が
不可能なブラックボックスとなり、無意識すなわち自然となる。
このような人工知能が引き起こす人間にとっての不利益は、
いつか自然災害として扱われるようになるだろう。

そうなれば、自動運転車の事故の責任が問われることは
やがてこなくなるはずだ。

様式美

あるものが、何故それがよいのかを説明されても
なお感銘を受けられるものには、もれなく様式美が
備わっていると思う。

お笑いで言えば、歌舞伎や落語はもちろんのこと、
ダチョウ倶楽部の芸も、特定の世代にとっては
様式美を備えた伝統芸能の一種だと言える。

このように、理屈による部分への解体に耐えられるだけの
形式をつくるということを、一人の人間が一生のうちに
成し遂げるというのはものすごく難しい。
時間の制約上、単純に試行回数が足りないのだ。

歴史は繰り返されることでかたちが定まっていき、
やがて伝統になる。
歴史に語り手がいることから、必然的に伝統も語り手を
背負うことになるが、いろいろな語り手が繰り返し語ることで
語り手の存在自体はすり減っていく。
いつしかその背後にいる語り手が消えたとき、伝統が生まれている。

人工知能が膨大な学習の末に得ているものは、ある種の伝統だろうか。
訓練データの背後に存在する正義は消えることがあるのだろうか。

御柱祭2016

諏訪大社上社の御柱祭に参加してきた。
全力を発揮すると翌日に筋肉痛がくる程度には
まだ代謝が落ちていないようだ。

前回の2010年にも参加して、そのときは木落としを
やらせてもらったのだが、今回は本宮四ノ柱の山出し
前半部分の曳行をやらせてもらった。
4/2朝7:30曳行開始。やや雲はあるものの晴れ間が
広がり、東の空には八ヶ岳が気持よくそびえていた。

綱置場〜一番塚〜柳沢の交差点あたりまではかなり平和で、
日本酒やビールを飲みながらヨイサと声を出す。
辛かったのは土埃くらいだ。

柳沢では男綱が外になるが、その内側にいたので、
男綱が内側に入るのを阻止するために全力で押す。
今見返すと全然角度がきつくないのだが、ダメージはでかい。
そこからはカーブの連続で、男綱が外なら足で押す、
内なら全体重を載せて引く、の繰り返し。
腕よりも小綱を握る手の痛みの方が辛い。
大曲がりを曲がりきる直前でタイムアップで離脱。
土埃と汗で体中真っ黒だった。

柳沢あたりから力を使うようになってわかったが、
掛け声と音楽はあるべくして存在している。
本当に力を発揮しようと思ったら声を出さないと出きらないし、
その力を全員が合わせないと寸分動かないのだから、
タイミングとりに掛け声は最適だ。
やっとこさ動いた後であの音楽が流れるとものすごく気持ちがよい。


御柱祭は数えで7年に1回行われる。
徐々に変化はしているようだが、大枠としては1000年近く
同じままなのだろう。
山から切り出した10tもの大木を人力で神社まで運ぶなんて、
現代の常識で考えれば馬鹿みたいな行為だ。
それを、死者が出てまでも形式を保存するというところに、
ある種の人間らしさがあるのだろう。

意味など存在しなくてよいのだ。理由はいくらでも後付けできるだろうが、
純粋にその形式を引き継ぐこと自体が、一つの全体を作っている。
理屈を積み上げてできたものは、おそらく1000年も続かない。
歴史とは語られた経験であるが、伝統とは語り手が消えた歴史なのかもしれない。

shiny fluid example

昨日shinyに追加されたfluid dynamicsのexampleが
とてもgolangらしくてよい。

・main()はイベント処理に集中、図の作成は別のgoroutineで行う
・Crosses(StageVisible)で表示中かどうかの判定
・マウスイベントや図の情報は共有データとし、MutexでLock/Unlock
・表示中はtickerで60Hz毎にsimulate()を回す
　（1/60秒毎に発火するchannelを使用）
・非表示中は短絡させ、simulateを行わないようにする
・図ができたらchannel経由でイベントを送る
　（マウスやキーボードのイベントと同列で他のgoroutineがイベントを発火できる）

特に最後のポイントは結構肝だと思っている。
これまでいくつかのGUIライブラリを触ってきたが、
golangでchannel経由のイベント処理をちゃんと実装して
いたものはなく、ほとんどがコールバックだった。

stでもchannelでイベント処理の振り分けを行っているが、
こういうことができると全体の見通しがよくなってすてきだ。

スーホ

スーホの白い馬
すーほのしろいうま
いまほーすのうしろ
今ホースの後ろ

April Fool

April Fool
I proof all ←大丈夫ですかねぇ

エイプリルフール
増えるプール入り