Ruby Gtk で遊ぶノート

(この記事はメモ書きの状態です)(そのうちまとめるかも知れませんが、当分はゴチャゴチャです)

 趣味の日曜プログラマにとって、Ruby/Tk は必要十分な選択肢であった。特にWindowsではTk::Tileを用いることで十分に綺麗なUIを作ることができる。ところが、Ruby/TkはRuby本体から削除されてしまった。LinuxやMacではTkのツールはやや汚い。仕方ないのでRuby/GTKを少しずつ勉強してみることにする。

Github 公式サンプル
https://github.com/ruby-gnome2/ruby-gnome2/tree/master/gtk3/sample/misc

Ruby/GTK でよかったこと

・Webkitが使えるのでウェブページが表示できる
・gem install でパスワードを求められ、ライブラリがインストールされるという新鮮な体験がある
・PDF もすぐ表示されて嬉しい
・Glade が便利
・ちゃんとアップデートされている

Ruby/GTKの微妙なところ

・C言語のバインディングなので、メソッド名などがRubyっぽくない。特に signal_connect
・Ruby/Tkでは自動化される低レベルな処理も明記しなければならない傾向
・ブロックを使用した記述がすくない(勉強しているうちに正しいやり方がわかるかも)
・GIO yard server -g で勉強しにくい(GObject Introspection で自動生成しているため)
・日本語ドキュメントが古い

Ruby/Tk の方がよいところ

・潜在的普及率が高い(PythonでもTkinterが結局一番使われているという)
・Windowsでの動作に一定の安心感があった。
・手軽感、充実した資料(Linuxへの導入のしやすさは×、WindowsでもTclの拡張ライブラリの導入は面倒)
・GUIライブラリの中ではRubyっぽいかわいい感じのする書き味

GTKとは何か

わからないものを、わからないなりに理解しようとすることは大事だと思われる。
Wikipediaによると、元々はGTKは、GIMPの実装のために開発されたツールキット。


https://ja.wikipedia.org/wiki/GTK%2B#/media/File:Free_and_open-source-software_display_servers_and_UI_toolkits.svg

なにやってんのか全くわからん部品がたくさん。とりあえずいい加減に理解。

glibc: Gnu標準のCライブラリ
GLib: 異なるOS間、CPU間の移植性を確保するライブラリだと。
GObject: Cでオブジェクト指向するためのやつっぽい。GTK+ 2.0 リリースの際に分離された。Wikipediaによるとサブクラスを作成するだけで数百行もコードが必要になるという。
D-Bus: プロセス間通信だって。
avahi:ネットワークに接続したとき、即座にプリンタを検出するやつらしい
X-Server: ssh -Xでアクセスするやつ。
Wayland: X-Serverじゃなくて、直接画面を描写して早いやつっぽい。2008年と最近。

GTKが保守本流ってことは何となくわかる。FirefoxとかThunderbirdとかもっさりしているけど、とりあえずちゃんと動く。

GTKとruby/GTK

GTKのレポジトリとか
https://gitlab.gnome.org/GNOME/gtk

ruby-gnome2
https://github.com/ruby-gnome2/ruby-gnome2

インストール

コントリビュータはktou氏がほとんど。
公式ドキュメントは更新が止まっていて情報も古い。そもそもLinuxのGUIを常用している人が少ないのかも知れない。

atk: アクセッシビリティ
pango: テキストのレンダリング、汎語?
GdkPixbuf: ピクセル単位で画像扱うやつ
GObjectIntrospection: introspection内省、内観、自己反省
https://qiita.com/groonga/items/71b145b37d77bd160bf2
C言語で書かれたライブラリーを各種スクリプト言語から言語バインディングを書かずに使える機能を提供するライブラリーです。とのこと。

Cairo: Xに依存しないライブラリ。Geckoとかに使われてるらしい。PDFやSVGにも出力。
Gstreamerってなんやろ。よく見るけど。
Clutter is an OpenGL-based ‘interactive canvas’ library

https://github.com/cedlemo/ruby-gtk3-tutorial のチュートリアルやってみる

ウィンドウ出す

delete-event つけないとウィンドウ消してもプロセス残る。

ボタンつける

ボタンに機能をつける

空のウィンドウをだすアプリ

ふう、もう疲れてきた。やっぱりRuby/Tkよりも記述量多い。

ボタン押すとウィンドウ閉じるやつ

配置の方法

配置の仕方はRuby/Tkでもいろいろあって、完全には理解していない。Gtkはもっと大変そう。
Gtk::Box
Gtk::Grid
Gtk::Fixed
あたりが基本っぽい。

グリッドによる配置

UIをxmlファイルに分けて記述

Gladeの使い方を覚える話になってくると、何となく頭の違う部分使ってる気がする。
このままGTKの機能を見ていくと、多分面白くなくなっちゃうのでウィジェットを色々動かしてみる。

カレンダーの表示

ダイアログを出す

ファイル選択ダイアログ

GladeというのでGUIを作成すると便利であると。便利そうだが、どこにどんなツールがあるか覚えないと使えない。

画像を表示する

テキストウィジェット

図形を描写したりするやつ

Cairoを使用する

リストボックス的ななにか

Gladeの暴走

理由はわからないが、Gladeが暴走することが結構ある気がする。何が悪いのかよくわからない。

簡易Webブラウザ

簡易Webブラウザ(Glade使ったやつ)

資料みっけ

PDFの1ページ目を表示するやつ

やっぱり、Webサイトの表示とか、PDFの表示とか、Ruby/Tkでやりたかったけどできなかった事が簡単にできて嬉しいわけです。

Gladeでのツールバーの作り方 資料

https://developer.gnome.org/gnome-devel-demos/stable/toolbar_builder.py.html.en
コードを一切書かなくてもそれなりにツールバーが作れちゃうので便利なのはわかるけど、ウチの環境だと高確率でGladeが暴走する。
他所ではGlade安定しているんだろうか。

最小限ターミナル

GTKソースコード見るやつ

Gtk2 と Gtk3 で微妙にネーミングが変わってるから注意。
Ruby/Tk が懐かしいので、tapを使って Ruby/Tk っぽい見た目にしてみた。
こっちの書き方の方が良いとは限らないんだけど、なんとなくそれっぽさがある。
GtkにはGlade先生がついているから、こんなGUIの入れ子関係を模倣したネストなんか要らないんだけどね。

キーバインドを拾う

ループ処理を行う

GLib::Timeoutを使う

GStreamerが難しい

せっかくRuby/TkではなくてRuby/GTKなので、音楽やビデオを再生したいのだが、GStreamerがよくわからなくて困る。GStreamerといえば、darknetで使うOpenCVをインストールするときにエラーを生じがちなアレというイメージ。



難しい、難しいと思っていても、時間をかけて眺めているとある程度わかってくることも多いので今日はこんな感じ。

最小限mp3再生Gstreamer

結局Gstreamerが何なのかはよくわからず。ひとまずplaybinを使うとmp3再生できた。他の形式も再生できて便利。

webm形式や、ogg形式のビデオもこれで再生できるようだ。mp4は音だけ出ている。
gstreamerはsynapticでパッケージ検索するだけでも大量にヒットするし、追加のパッケージを色々インストールすれば、mp4のビデオも再生できるのかも知れないが、よくわからない。

クリアコード謹製の資料
http://www.clear-code.com/blog/2014/7/22.html

テキストビューの内容を通知するやつ

チュートリアルを読んでみた

 glib-compile-resources でリソースをコンパイルできる。またGIOで、それらにアクセスできる。しかしRuby/Gtkでちょっとした個人ツールでは、ファイルのパスを直接するので十分だろう。Ruby/Gtkで作ったものを配布する場合にも便利かもしれないが、Ruby導入の時点で面倒なのでメリットは小さい。

 type-register ガシガシとサブクラスを作成して既存のウィジェットをカスタマイズする方法で作る時に、自作のサブクラスをGTypeとして登録するためにメソッドのようである。初心者なので、サブクラスというややこしいものは、なるべく作りたくない。作ったウィジェットが一つ一つクラスに対応していたらカチッとしていて心地良いだろうけど、Rubyのクラスの世界と、GTKの型の世界の2つの世界に気を使うのは面倒くさそうだ。GladeでComposite(複合)という項目をチェックするらしい。

 set_template で .ui ファイルを指定する。
 bind_template_child でアイテムを呼び出せるようにする。

 gschemaでセッティングを保存できる。glib-compile-schemas でコンパイル。Gio::Settings.new で呼び出し。これも知識としては知っておくが、使う機会はあるのかな…。GIOのリファレンスをざっと見ていてもたくさん機能があるようだ。

 感じたのは、英語がつらい。yard server -g によるお気軽な勉強方法が使えないので、Gnomeの情報やPygobjectの情報から勉強していくしかないけど、基本的には英語の情報に当たるしかないようだ。趣味でポチポチやってるだけの人にはつらいところだ。。

Crystal言語がはやい

すごい!

素人でも気軽にたのしくRubyで高速計算する方法を探してきた。そしてNArrayをみつけた。しかし、数年ぶりにNArrayを超えるかもしれない逸材を発見してしまった。Crystal言語である。Crystal言語は、マルチプロセスに対応する気もあるらしく、xargsやparalellジェムを日々愛用している私はとても期待している。そんなCrystalのメモ。

開発者

アルゼンチンに住んでいる

コンパイル

速度比較

色々な言語で計算速度を比較してみたを参考にライプニッツ級数の計算で測定した。グラフを見ると、Rubyと全く同じコードにも関わらず、コンパイル時間を含めてもNArrayより早いことがわかる。これはただ事ではない。PCによってはもっと差が出る印象。

Ruby & Crystal

NArray

 realusersys
Ruby61.887s61.812s0.028s
Crystal (コンパイル&実行)7.923s7.900s0.196s
Crystal (最適化コンパイルしたものを実行)6.821s6.812s0.000s
Numo::NArray10.163s9.860s0.256s

ほんの少しさわってイマイチに感じるところ

半日さわった印象としては、型のキャストがわかりにくい。たとえばUInt8をfloat32やfloat32に変換する方法をググってもしばらく見つけられなかった。.to_fでよいらしいが、.as(Float64)とかで統一してくれた方わかりやすい気もする。あと、どうしてもコンパイルに時間がかかる。kemal(sinatra相当)使ったコードをコンパイルするだけで体感数秒以上かかる。GUIライブラリが弱くてキャンバスに図形描写したりするの苦手っぽい。ライブラリ眺めてる pointerof とか出てくる。コンピュータに強い人にとっては長所なんだろうけど。

よいところ

crystal shards コマンドが優秀。Rubyもこうあるべきだと思う。htop眺めてると、files = Dir.glob files.each とかやったときに自動的にマルチスレッドしてくれているっぽい。だいたいRubyと同じ。コミュニティの雰囲気も洗練されていて悪くなさそう。とにかく処理が早い。

追記:さらに1日さわってRubyとの違いを感じたところ

上記は、数値計算のことだけを考えていたので、オブジェクト指向の部分、クラスやメソッドなども少し触ってみたらRubyとかなり違いがあった。まずは型チェックが厳しい。ある程度はコンパイラ?が型を推測してくれるが、必ずしも推測万能ではないので、推測が難しいところは自分で型を指定していく必要がある。特に引数のチェックは厳しい。Arrayとかは最初に型を指定する。こんな制約もあるので何でもかんでもArrayを使うべきではなく、構造体とかタプルとかSliceとか用途に合った型の採用を検討するほうがいいかも。デバックの時にRubyとはかなり頭の切り替えが必要そう。いろんな型を受け取るメソッドはオーバーライドという書き方も使って行く。ゲッター、セッターは、attr_readerの代わりにgetterとか名前が違う。irbがないので、crystal playを使う。(こういうのはRubyにも搭載されているべき。Jupyterに依存するべきではないと思う。)cloneとかequalとかto_jsonとか動かないので、自分でコードを書く必要がある。そして便利なマクロが用意されているので、それを使う。マクロは便利そうだが直感的になんとなく闇を感じる。2つobjectをreternするときはタプルが便利。injectのかわりにreduce、””と”意味が違う、require_relativeない。プライベートメソッドはprivate def hogeと書く。Threadとかも何気に動くっぽいけど、spawn使えとのこと。forkもあるっぽいが試していない。RubyはC言語のライブラリをラッパーになって処理を呼んでるだけの場合も多く、そういうものはCrystalに書き直しても大して早くならない。そのため「Crystalizationで爆速!」が(俺の趣味レベルで)実現できる範囲は思ったより狭いかも。コミュニティ若いので、ちょっとドキュメント書くだけでも歓迎される雰囲気がある。すごい。

使い分け

NArrayの方が可読性がよいので、特にスピードを求める部分だけCrystalで書けばいいと思う。素人なので、難しいことは考えずにパイプでつないだり、普通に実行結果をファイルに保存して、処理をつないでいけばよいと思う。Rubexとかもいいけど、やっぱり簡単な方がいい。

ビットコインと癌とひらめきとネットワーク

ずっと前からぼんやり考えているアイディアと、昨日思いついたアイディア。

 ビットコインの仕組みがよくわかっているわけじゃないけど、癌との何らかの類似性がないかを考えている。組織の定常性が保たれている状態から、ある時から癌が発生していく状態が、ビットコインが負のサイクルに陥って終焉していく状態に似ているのではないかという妄想である。そもそもビットコインが終焉していくのがどういう状態なのか誰もわからないので、そんな類似性が本当にあるのかわからないが。ビットコインが終焉する段階では、マイナーの数も減り、簡単に誤ったブロックを生成することができるようになり、そのようなブロックがあちこちで生み出されるような気がするのである。そのような状況が本当に訪れるのかわからないが、癌と類似するのではないだろうか。この世の中の安定性や定常性は、手段があっても時間内にできないという事を基盤に保たれていることが多く、暗号もその一つだ。そのあたりと癌の類似性がどうなっているのか、なんとなくひっかかるものがある。そこらへんに若い頃は癌が発生せず、年齢を重ねてから癌が発生する秘密が隠されている気がする。とはいっても、生体はビットコインよりもずっと複雑だし、具体的にどのようにアナロジーを考えればいいのか全くわからないけどね。

 もうひとつは昨日思いついたアイディア。ディープラーニングで、特徴次元を落とした多次元空間を探るのは難しい。一つの学習モデルが作られたとしても、それを他の構成のネットワークに流用することは難しい。こういうのを人間はどうやってやっているんだろうか。僕が何かを考えていて、一番楽しいのは、全く別の場所のアイディアを他の場所に投影すると、意外な類似性を示すときだ。例えば、(本当にそんな類似性があるのかわからないが)上の段落で書いたビットコインと癌のように。これは、ある場所で使っている認識の構成を、他の場所に流用することとも考えられるかも知れない。つまり、人間は、特徴空間の構造を識別して、他の特徴空間と比べたり、ある場所で使っているネットワークを他の場所でも使ってみるというようなことが柔軟にできるのかも知れない。

 忘れないように書き留めておく。

Chainerの勉強中

とてもわかりやすい本です。読みながら勉強。

途中でお世話になったサイト 〜Pythonの基礎知識〜

Pythonの知識ゼロなので、適宜ググりながら読み進める。
Python: オブジェクトのメソッド一覧を取得する
Pythonでのファイル操作
クラス継承
Chainer v1からChainer v2への移行
Python入門 – リスト・タプル・辞書
__future__ モジュールについて

Rubyと違うところなど

・Pythonでは関数はオブジェクト
・Pythonでは空白インデントが意味を持つ
・Pythonではファイルが自動的にモジュールになる

Chainerのバージョン確認

Configオブジェクト

trainモードとtestモード

Variableクラス

numpy.ndarrayまたはcupy.ndarrayを梱包している。
どの関数から生成されたか記憶してあるため、計算グラフを構成できる。

ネットワークのグラフを描写する

誤差逆伝播の対象にするかどうか

Functionクラス

大量にあってどれが大事なのかよくわからない
https://docs.chainer.org/en/stable/reference/functions.html

Linkクラス

全結合のもの

p77 Chainerの主要クラスの関係性が秀逸

Optimizerクラス

Trainerクラス

なんとなく半分ぐらいわかった気になったので、exampleのコードを改変して遊んでみる

最小限MNIST

この資料が大変よい
Chainer: ビギナー向けチュートリアル Vol.1

MNISTでCNNもやってみる

Mnistのデータを3次元で呼ぶ必要がある。RubyとちがってMapできないから面倒だなと思ってforループで変換していたが、
chainer.datasets.get_mnist(ndim=3)
すればよいのだ。

MNISTのはずれ画像を眺めてみる

人間でも間違えそうなものと、人間だったら間違えないものが含まれている。とくに8は間違いすぎていると思う。
全体的に値の少ない文字のほうが間違いにくいという傾向があるように思われて、とても興味深い。










データセットクラス

データセットもクラスであると。(numpy配列, 正解ラベル)タプルの集合みたいになっている。
あらかじめchainerに同封されているサンプルデータもある。
・MNIST dataset
・CIFAR-10 (3, 32, 32) 50000 10000
・CIFAR-100 (3, 32, 32) 50000 10000
・Penn Tree Bank dataset as long word sequences (929589, 73760, 82430)
・Penn Tree Bank word vocabulary (dict 単語=>数字)
・SVHN dataset (3, 32, 32) 73257 26032

オプティマイザ

・AdaDelta
・AdaGrad
・Adam
・MomentumSGD
・NesterovAG
・RMSprop
・RMSpropGraves
・SGD
・SMORMS3

イテレータクラス

以前は自分でfor文書いてたらしい
・SerialIterator
・MultiprocessIterator

アップデータ

・Updater
・StandardUpdater
・ParallelUpdater(parallel GPU Updater)
・MultiprocessParallelUpdater(multiprocess parallel GPU Updater)

旧世界のはざまで働く人のよくある悩み

 趣味でパソコン遊びをしてきたが、そうこうするうちに、社会がだいぶ時代に追いついてきた。そしてプログラミングや人工知能の重要性が私の住んでいる場末の旧産業の世界でも認識されるようになってきた。数年前にターミナルを開いていただけで「遊ぶな!」「あやしいことをやっている」と白い目で見られ迫害されていた状況とは隔世の感がある。そうすると今度は「もっとやれ!」と言い始めるのだから勝手なものである。大変ありがたいことだと思うが、そう言われても、数学は全くできないし、プログラミングもできないので困ってしまう。

 どこでもそうだと思うが、旧産業世界では、品質の維持・向上のために人間を限界まで使い倒すシステムが確立されている。並大抵のことでは、プログラミングなどを勉強する人は出現しない。なぜなら、そんなことをして余計な人生リソースを費やしていたら旧産業世界で生き残れなくなってしまうからである。私は、旧産業世界で生き残るために、申し訳ないと思いながらも限界まで手を抜いてきたし、同僚には悪いと思いながらもサボっていた。

 さらに悪いことに、旧産業界では、人手不足(給料不足ともいう)が横行し、人々が自分を守ろうとする手段の一つとして、他人にも work of proof を求める風習が横行している。ここでの work of proof は、本当にビットコインのような意味での work of proof で、これだけの仕事量を耐えたのだから順番に品質認定しようという理由で、意味があるのかどうかよくわからない負荷を加え続けるシステムである。同様のことが、レイヤーを変えて日本中で横行していると思う。あたりまえだが work of proof の作業をしている CPU は他の仕事などこなす余裕はない。

 それにあまり認識されていないが、人間の可処分思考時間は一定である。また強烈な心情的圧迫の元で何かを決定するためのメンタルも一定である。安全管理と称して、目に見えるところにあるゴミを、最終的には人間の可処分思考時間のなかに押し込んで、見えなくするのが流行してるが、贔屓目にみても無能であり、もっとはっきり言えば恥知らずである。これは単に悪影響を測定できるところから、測定できないところへ押しやっただけだ。問題はこのような所為を指摘して改めさせることがとても難しいことである。

 可処分思考時間やメンタルを削られる状況で、新しことを考え続けるには、その場を支配する空気…倫理を無効化するように、常に頭の中でスネイプ先生のように反対呪文を生成して唱え続ける…。

 どうしてこんな愚痴をわざわざこのサイトに載せたのかというと、意外とこの愚痴は、自分のことではなくて、日本中で共通して発生している現象なんじゃないかと思うからだ。日本からイノベーションが出なくなったと言われて久しいが、その理由を細かく突き詰めてくると、このあたりに理由があると思う。日本ではあまり評価されていなかった人が、海外に行って成功する事例をよく聞くけれども、その理由もこれで説明できると思う。

 では一体私達はどうすればいいのか? というのは、個別の組織や産業にとどまらず、家庭や都市・地方の問題にまで話が及ぶため、非常に難しい。。あるいはどうしようもないのかもしれない。

 というめくるめく愚痴、およびサイトに来た人を追い払うのはそこそこにして、ChainerやKerasの勉強をしないとな。。

目標逆算と予想介入 2つの考え方

これから1ヶ月〜数カ月ぐらいかかるような大きめ仕事が増えていくと思うので、昔の記憶を思い出して書いてみる。

 これから書くことは、私が大学生の時に学祭の準備をしながら考えたことである。だから本当はかなり前の話になる。

 社会に出てからは「何をやるべきか」について自分の頭で考えて決断しなければならないような機会は少なかった。避けてきたと言ってよいかもしれない。世間では、自分の頭で考えることが大事だと言われている。しかし実際には、自分の頭で考えることが望ましいとは限らない。狭い視野で考えた結果が、集団心理に流されるよりも正しいという保証はどこにもない。個人の狭い考えで何か事を起こして、いざ問題が起こったら大変である。そうならないように、組織は大きな力で個人が自分の考えで行動しないように工夫している。それに第一、自分の頭で考えるということは大きな苦行なので、あまり続けていると精神がまいってしまう。こうしてみると果たして考えることが良いことなのかもわからない。…しかし、今日はその話はしない。

 2つの異なる考え方がある。これを「目標逆算」方式と「予想介入」方式と名づけることにする。世の中には仕事のハウツー本がたくさんあるので、それぞれの方式に、それらしい正式名称があるのかも知れない。とはいっても、大学生が考えたことなので、大した内容ではない。

 大きなプロジェクトに取り掛かるとき、人はそれを細かい仕事に細分化する。大きな仕事を、扱いやすい適度なサイズまで小さく切り分けて、紙に書きだしてリストアップする。頭の中だけで、仕事を整理しようとすると、やらなければならない事に抜けが生じるので、紙に書き出すことが大事だと思う。大学祭の準備で、僕が仕事が進まずに困っていると、ある先輩が「困っていることを全部紙に書きだしたか?」と尋ねてきた。紙に書いて、問題を実際に実行可能なサイズまで分割することが、とても大事だというのだ。これが「目標逆算」方式の考え方だと思う。

 大学生はみすぼらしいけど、夢がある。大学祭でも大きな理想を立てる。「これがやりたい」「あれがやりたい」と大きなプロジェクトが立ち上がる。一度目標を立てたら、その目標を達成するために必要な「やらなければならないこと」をノートにリストアップする。まず目標を立てて、逆算して仕事を分割し、最後に実行するので、これを「目標逆算」方式と名付けた。この、目標逆算方式は、確かに最初はうまくいくのだが、やがて目標と現実の乖離が目立ち始め、締め切りが近くなると、「あれも間に合わない」「これも間に合わない」として、否応なしに目標の方を下げていくことになる。少なくとも私の場合はそういうことが多かった。そして、大学生らしく、最後は徹夜の突貫工事が始まるのである。そして、プロジェクトが成功しようがしまいが、終わったあと、ちょっとした心の傷を負うのである。(それもよい思い出である)

 どうして、必ずこうなってしまうのか、うまくいかないのか。悩んでいた時に思い浮かんだのが「予想介入」方式だった。これは、目標逆算とは逆の方法だ。まず、目標は立てない。何をやろうとも考えない。もしも何の対策もせず、地球を放置していたら、この先ものごとがどう回転していくか、人々が何を重い、どう行動するかを、勝手気ままに予想する。その上で、望ましくない未来が生じる兆候をみつけた場合は、それに対してどのような変化を加えればいいか、介入すればいいかを考えるのである。この方法を使うと、「目標逆算」では想像していなかったようなボトルネックに気が付きやすくなる。それに目標逆算方式よりも、人々の気持ち…たとえば怠け心とか…汲んだ予想が行われるので、たとえ成果があがらなくても、「予想した未来よりはマシな結果になったな」と考えて、心の傷も負いにくいことがわかった。この方式を未来の予想に介入するため「予想介入」方式と名付けた。しかし最終的なアウトプットが、先ほどの目標逆算方式よりも高くなるとは限らない。

 以上が、つまらないが大学生のときに考えたことだ。自分の頭で考えて行動している人たちからみると(そういう人が多いとも思わないが)、ごく当たり前で初歩的なことが書いてあると思う。

 私は「予想介入」が苦手だ。だから、もし「目標逆算と予想介入のどちらがより高度な方法なのか?」と言われたら、「たぶん、予想介入の方が高度な方法なのだと思う」と答えるだろう。なぜならば、予想逆算は自分自身に対する予想ふくむ。つまり自己言及的要素があるためメタ度が高く難しいと思われる。また、予想逆算は、自分自身の心の中にあるポリティカル・コレクトネスを一時的にoffにして、自分自身の直感的なセンサーに正直になる必要がある。これも大変難しいことだ。

しかし、世の中には予想介入にばかり特化して、およそ目標逆算はできないといった人々も確かにいるらしく、その人たちはその人たちで、困ったものだろうと思う。

 実は最初は、目標逆算方式のことを「理想追求方式」と名付けようと思っていた。でも予想介入方式が理想を追求していないのかと言ったら、そうじゃないと思う。このあたりは「理想」、ひいては「自尊感情」、「モチベーションの維持」などの問題が絡むので考えるのが難しいところだ。そういうわけで十分に頭の中で整理できないので書けない。きっと誰かがいいことを書いているのだろうが、どうやってググればいいのかもわからないので調べにくい。

人工知能に神を期待すること

タイトルは釣りみたいなもので内容も中2みたいなエントリーだが、4月ごろからフワフワと考えていて、なかなか文章にできないことをアウトプットしてみる。

人工知能脅威論ってネット上でもよく見かける。たとえば

 > 将来は人工知能が全部決めて人間が従うだけ
 > 人工知能が人間に対抗してくる 

などなど。でもディープラーニングによる画像認識のようなちゃちなソフトを人工知能と言うなら、これはおかしな話だと思う。
なぜこんな認識違いが起こるかというと、実は人工知能が脅威だと思っている人と、そう思っていない人ではそもそも人工知能に求めている「機能」が違うんじゃないかっていう話です。

少し話が飛躍するかもしれないが、どんな組織でもいいので、日本型組織を想像してほしい。
働かないトップがいる。実務家がいる。

トップは必ずしも物事の詳細について詳しいわけではない。実務家ほど仕事ばかりやっているわけでもない。全体の方向性を決めたり、たまに口を挟む程度で、実権はあまりない。単なる偉い人だ。
一方で実務家は現場で指揮を取ってあくせく働く。知識も経験も豊富だ。何か決定したら、トップに奏上する。トップはこれを承認する。

実は、トップは余裕がある組織でないと養うことはできない。実務家だけの組織や、実務家がトップを兼任している組織はたくさんある。
それでも、僕は、働かないトップがいる組織の方がパフォーマンスがいいのを何回も見てきた。働かないトップを支えるのは日本型組織の一つの理想形だと思う(多分)。ただし働かないトップを養うためには組織の余裕がかなり必要になる。ある意味贅沢品である。(豊かであるからトップが養えるのか、トップがいるから豊かなのか、というのは難しい問題である。)

ここで、トップの果たしている役割と、実務家の果たしている役割は全く違う。
にもかかわらず、トップは実務家のように知識や実行力が豊富であるべきだとされ、実務家はトップのように品格のある人であるべきだとされる。

トップの果たしている「機能」は明らかに重要だが、その意味・内容は実務家のもたらす「機能」と違って明瞭ではない。トップとは何をしている人なのだろうか。

私は仕事でも、あえてこの「トップ」の持つ役割・機能を意識して振る舞うときがある。つまり自分は何もしなくても、ただ黙って傍らで他者の仕事を眺めているだけで、自分は何らの知識や技能がなくても、何もしないよりはうまく仕事が回転していくことをよくある。本当に何もしていない。ただ横にいて見ているだけなのだ。誠に非科学的な話かもしれないが、この時、私は心理的には上司や同僚や部下の心理的負担に手を差し伸べている。お金に例えると、自分はなにもしていないが精神的に作業に「出資」しているような状態だと思う。私は実際には何も働いていない状況ではあるが、人々は私の精神的な出資率も高いと判断して、私も仕事の完遂を願っていると判断して勝手に行動してくれる。そして、終わったあとなぜかとても感謝される。

一方でこの精神的な出資のことを意図的にまたは無意識のうちに軽視していると、どんなに実務能力があっても、あいつは「未熟」であると影口を叩かれる。

このような状況は誰しも経験するのではないだろうか。

上司がまだ仕事をしている時に、特に用事がなくても居残ってしまう日本人の奇妙な性質もこれで説明ができる。例えシゴトをしていないくても、上司と一緒に居残りしている彼は精神的に出資をしているのだ。そしてこの精神的な出資が、とてもありがたく感じられるのである。(念のために書いておくと、そのような仕事法の総合的な善悪までは私は判断しかねる。)

出資者には当然要件があって、それは「仕事の成功を強く願っている」ということが必要だ。逆に「願う」ことさえできれば実務能力はゼロでも構わない。

では「願う」とは何なのだろうか? 既存の枠組み…たとえば強化学習の延長線上で、それは実現できるのか?

その答えは現状では2通りあると思う。(1)マシーンは願っているふりをすることができる (2)マシーンが願うことは実現できていない。
両方共正解だ。欲望するコンピュータというものがまだ開発できていないので(2)は当然だ(本当かな?)

それより(1)に注目したい。人間は仮想的なマシーンを頭の中に構築することで、願っているふりをするマシーンを作ることができる。え?意味がわからないって?もう少し読み進めてほしい。

組織や国家は、昔から膨大な予算をかけてこれをやってきた。卑弥呼の時代から、人々は祈祷をしてきた。シャーマンとはひょっとすると、願う力の強い人たちである。膨大な僧侶を雇い、彼らは鎮護国家を祈祷…「願って」きた。僧侶は膨大な知識を使って仏教理論を構築していった。

奈良の大仏様をみてみよう。人々はコレが銅の塊に過ぎないことを知っている。しかしそれは同時に宇宙の真理を人々に照らし悟りに導く仏なのである。平安時代の人々は仏教による鎮護国家を目指して、真面目に国家予算を使ってこの大きなオブジェを作った。

このオブジェは実質的には何の機能も持たないが、「願う」機能を持つと想定されるオブジェであり、人々を何もせずに「見て」いるのである。つまり擬似的に「トップ」の機能を実現したマシーンの一種だと言ってよいかもしれない。

あるいは、本当の意味で作られたものは、「毘盧遮那仏」という概念であり、この仏像はそのガワに過ぎないにしても…
「大仏様」は人々の頭に毘盧遮那仏という概念を無理なくインストールするための装置だと考えると面白いと思う。

つまり、この点でも歴史は繰り返しているのだと思う。作ろうと思えば、「トップ」すなわち「神」の機能を持つ「人工知能」は作れる。なぜならば「人工知能」に求められている機能は、「神のような実務能力」ではなく「神」の能力なのである。とすると必ずしも高度な実務能力を実装する必要はないからだ。昔から多くの天才的な「神エンジニア」たちがが国家のために働いてきた。そして現在も…

さて君たちも神を作ってみる気になったかな?
一つアドバイスするなら、神を作りたいなら必ずしも人工知能は要らないということだ。

まあ中2的文章を、これ以上書くと自分でも恥ずかしくて恥ずかしくて大怪我しそうなのでこのへんで。でも書かないと気が済まなかった。

今日の落書き bioruby を眺めてみた

正確にはbiorubyのyard documentをながめてみた。

眺めた感じだと、Bioモジュールの中に、「手法/プログラム」を扱うクラスと、「ファイル」を扱うクラスと、「データベース」を扱うクラスみたいなのがあるっぽい。
ところがクラスのドキュメントにもOverviewやDiscriptionがないのが多くて、どのクラスが何を扱うクラスなのか、理解するのに若干の困難を感じる。

逆にいうとちょっとドキュメント追記するだけで、Pull Requestがはかどりそうである。多分そういうドキュメントが整備されていないクラスはあまり大事じゃないクラスなんだろうけれども、大事じゃないなら大事じゃないことがすぐわかるようになっててほしい。もうひとつOverviewが書かれないクラスが存在する理由は、同一ファイル内の別クラスに、ほぼ同様の記述があるからじゃないかと想像するが確かめてはいない。

ざっと眺めて感じたのは、Biorubyは処理をするための道具ではなく、ワークフローを書くことを意図しているのだろうということ。
速度を必要とする処理に関しては、C言語なんかで書かれた個別のプログラムを利用するべきなのだと思う。

逆にいうと、今後 Bioruby がどれだけ便利に使っていけるかということは、新しい手法/プログラム/ファイル形式が、どれだけ柔軟にBioモジュールに追加できるかどうか、という点にかかってくると思われる。(もちろんそのような公益な作業をしたい人よりも、単に追加されたクラスを使いたいだけの人が多いに決まっている。)

となると、なぜ2016年で開発が急にストップしているように見えるのかが気になる。

正直なにが何なのかよくわからないので今日はこのぐらい。

numo-gnuplot playground

今日の落書き red-arrowで遊ぶ

難しそうなので今日まで敬遠していたred-arrowを使ってみた。
公式の通りインストール。手順通りコピペでインストールしているだけなので何もわかっていないけど、そういうアホなユーザーも世の中一定数いるから仕方ないよね。Pythonの方もcondaでPyArrowをインストールした。

難しそうなので公式のexampleを試すだけ

パイソン

ルビー

おお、普通に動くじゃないか…。
/dev/shmというのが何か気になったのでインターネッツでググるとRAMディスクのことらしい(正確には違うらしい)。

ということは…なにこれすごい∑( ゚д゚ )

公式スライド

正直Webサイト製作に関するプロの道具であることを求めなければ、Rubyでデータ解析できる状況は十分に整ってきていると感じる。

機械学習に関してはscikit-learnのようなライブラリの力を借りる必要があり、pycallを呼び出して適宜red-arrowでデータを変換していくような使い方が望ましいのかもしれない。

RubyやPythonといった便利な道具があることを知らない or キャリアをまともにこなしていると学習コストを支払えない制度設計になっているために、プログラムでやった方が早いことも含めてプログラムと縁のない方法で仕事をこなさざるをえない非エンジニアの世界の方が、エンジニアの世界よりも広いのである。。