一人一党党

一人一人の、一人一人による、一人一人のための政治制度を!

わたしがprintf()デバッグをする理由

現在、私はprintfデバッグに頼っているのに、
わたしがprintf()デバッグをする理由
http://freak-da.hatenablog.com/entry/20090325/p1
が半分どころか3/4ネタのようなので、真面目に言い訳してみた。

Coders at Work プログラミングの技をめぐる探求 | Peter Seibel, 青木 靖 |本 | 通販 | Amazon
https://www.amazon.co.jp/Coders-Work-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%AE%E6%8A%80%E3%82%92%E3%82%81%E3%81%90%E3%82%8B%E6%8E%A2%E6%B1%82-Peter-Seibel/dp/4274068471
は生ける伝説達へ聞き取り調査の記録だが、驚くべきことに、彼らにはprintfデバッグを使う者がいるということだ。
Coders at Work on finding and preventing bugs
https://www.benkuhn.net/caw-errors

print文。
プログラミングの神は曰っているではないか。
『汝、誤りあらんと汝の思うところにprintf文を設え、再コンパイル、実行せよ。』
– Joe Armstrong
大抵は、単に値をprintするだけです。
私がプログラムを書いているとき、大量のprint処理が生じます。
そして、私がprint処理をコメントアウトしたり取り除いた時には、それらからprintされていた値は確かなものとなります。
取り除いたprint処理を再挿入することは滅多にありません。
– Ken Thompson
GHCには、様々なものをややバッチ処理的に印字する機能があります。
もしくは、それでも何が悪いのか分からないときが時々あるので、"unsafe printf"を少々バラ撒いて、何が起きているのか印字させます。
– Simon Peyton Jones
このうち、C言語の作者であるKen Thompsonがprintfデバッグを使うのは、驚くには当たらない。
C言語すら存在しない彼の時代には、マトモなデバッガは望むべくもないからだ。
しかしhaskellの主要開発者であるSimon Peyton Jonesと、Erlangの作者Joe Armstrongは違う。
これらは新しいプログラミング言語であり、それなりの各種ツールが利用可能な時代に作られている。
そして、情報不足を理由にそれらの各種ツールを避けるには、彼らはプロフェッショナル過ぎる。
なのに、特にJoe Armstrongはprintfデバッグが第一選択だ。
 
私はbrainfuckJITコンパイラを書いたとき、GNU gdbデバッガを沢山つかった。
GNU CとUNIXシステムコールだけで実行時アセンブラ ( ソフトウェア ) - 一人一党党
コンパイラの場合、生成した機械語命令が正しく動いているか確認する必要がある。
しかしデバッグ対象が機械語命令の粒度になると、printf呼び出しの影響が大きくなりすぎる。
機械語命令一個の動作をみるのに、機械語命令十個程度を挿入するのだから、元のプログラムが1/10しか含まれていない別物をデバッグすることになる。
一方、自作のプログラミング言語処理系上で動くプログラムを書いている現在の私は、gdbデバッガを使わない。
デバッガは自作の言語処理系には対応していないからだ。
自作の言語処理系はC言語で書かれているので、言語処理系自体をデバッグするにはgdbデバッガは有効だろう。
だが、そのデバッグ機能を、もう一段上の言語処理系や仮想マシンインタプリタを越えて使うのは、デバッガ自体をその仮想マシンアーキテクチャに移植するのと等価だ。
移植作業と同等の手間がかかるだろう。
Coders at Workに登場する巨人達は、ほとんどが新しい処理系の作者だ。
彼らに必要なデバッグツールは、既存処理系のものではなく、まだ見ぬ新しい処理系向けでなければならない。
これが、彼らがprintfデバッグを重視する理由だと私は考える。


勿論、大抵のソフトウェア開発では、一見すると、自作の言語処理系をデッチ上げることはないように見える。
だが、抽象化を駆使して、ソースコードの再利用性を高めたりサイズを圧縮するプログラミングスタイルでは、知らないうちに自作言語処理系を作っている可能性が高い。
ARMプロセッサなどいくつかのCPUには除算などの命令がなく、これらのCPU向けの処理系では、除算処理を標準ライブラリ内の関数として実装している。
逆に言えば、あらゆる箇所で使う処理を一つの関数に纏めて抽象化するのは、新しい命令を処理系に追加するのと同等だ。
関数=追加命令が多くなるほど、自作の言語処理系との差は埋まる。
高階関数を使えば遅延評価など制御構造まで抽象化でき、ソースコードレベルではhaskellの真似事に手が届く。
本物のhaskellに対応していないデバッグツールが、そのようなhaskellモドキのコードに対応できるはずがない。
ドメイン固有言語、仮想マシンインタプリタ、新しい言語処理系…、これらは抽象化のうち、明示的に既存言語の枠を踏み越えたものに過ぎない。

つまり、それぞれのデバッグツールには、扱える言語に対応した、扱える抽象化の限界が存在する。
その限界を越えた抽象化を欲するなら、新しい言語を生んだ巨人達と同様にprintfデバッグを使うしかない。

ディープラーニングによるフェイクメディア

今日、本屋で立ち読みしたら、
特集 だますAI vs 見抜くAI | 日経サイエンス
http://www.nikkei-science.com/201901_037.hml
が目に入った。
内容としては、
まるで本物 「ディープフェイク」動画の危険性 (1/4) - ITmedia ビジネスオンライン
http://www.itmedia.co.jp/business/articles/1805/10/news009.html
より少し新しめ&詳細な情報が載っている。
偽造写真は昔からあったが、今は映像すら偽造できる時代らしい。
「見抜くAI」は一つでもボロを見つければ勝てるため、同レベルの技術量の場合、「だますAI」の方が極めて不利らしい。

しかし、「だますAI」は「見抜くAI」だけ相手にしていればいいが、「見抜くAI」は「だますAI」だけでなく「本物のメディア」も検査しなければならない。
不特定多数が動画をアップロードする現代では、藁の中に針が混ざってないか調べるようなものだ。
実際には、多くの人々に広がった有名なもの、つまり、騙された人が既に沢山いて手遅れのものに検査対象を絞ることとなろう。

さらに面倒なのは、「見抜くAI」が行うのは判定までで、説明はしてくれないことだ。
昔の偽造写真鑑定は、鑑定士も人間だから、他の人間が鑑定士の思考・作業を辿り再検証することができた。
しかしAIは人間とは大きく違う思考・作業をするため、人間がAIの思考・作業を再検証するのは絶望的だ。
ならば、AIはAIによって再検証すればいいかというと、二つのAIに食い違いが生じたとき、どちらのAIを信用すべきかが問題になる。
これが人間であれば、鑑定結果を疑っている人自身が検証作業を行えば良い。
他人と自分、食い違いが生じるなら、どちらを信用すべきかは自明だからだ。

スカイネット誕生の日は近い。

参考
スカイネット
http://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AB%E3%82%A4%E3%83%8D%E3%83%83%E3%83%88

フフ、OSの性能の差が、人気の差と逆であることを教えてやる

備忘録。

本の虫: C++標準化委員会の10月の興味深い文書
https://cpplover.blogspot.com/2018/10/c10.html

不自由で低能なWindowsはプロセスの作成もスレッドの作成も遅いし、ましてやファイルの作成に至っては、i7でNVMeのSSDを積む高性能なコンピューター上で動くWindows 10がRaspberry PiとSDカード構成のRaspbianにすらパフォーマンスで負けるという信じられないほどの低能を誇っている。

Benchmarking OS primitives - Bits'n'Bites
http://www.bitsnbites.eu/benchmarking-os-primitives/

プログラムの起動速度でもWindowsはRaspbianに負けているが、こちらはストレージの性能差は影響しないので、ファイル生成よりは信じ易い。
ちなみに、Raspbianはdebian GNU/Linuxの派生なので、Linuxの一種。
Benchmarking OS primitives - Bits'n'Bites
同上

Obviously each operating system has its merits, but in general it seems that Linux > macOS > Windows when it comes to raw kernel and file system performance.
明らかにそれぞれのOSにはそれぞれの長所があるが、
一般的には、Linux > macOS > Windowsの順でOSカーネルファイルシステムの性能が高い。

これは正に、使える人が多いOSの順と逆だ。

--

題名の元ネタは「機動戦士ガンダム」。

Betfairから見た自民党総裁選

最近は自民党総裁選挙の報道が賑やかだ。
安倍首相と石破元幹事長の一騎打ちらしい。
安倍氏が優勢なようだが、それを具体的な数字で表現してくれるものの一つが、賭博サイトだ。
国内では賭博サイトは法律に触れるので、海外サイトから探すことになる。
賭博サイトとして有名なbetfairをみると、直接総裁選を扱っているわけではないが、安倍首相の任期についての賭け
Shinzo Abe to leave before end of 2018
https://www.betfair.com/exchange/plus/politics/market/1.144153051
を見つけた。
「2018年までに安倍氏が首相を辞めるか?」という賭けに対し
辞めない 1.08倍 - 1.2倍
のオッズがついている。
(「辞める」側のオッズは、対応する「辞めない」側のオッズより甘いので省略。)
オッズではなく100分率の確率に直せば
辞めない 83.3% - 92.6%
となる。
衆参両院の議席の半数を自民党が握っている状況に於いて、自民党総裁が首相になれないという事はないだろう。
逆に言えば、総裁選に落ちれば、新総裁に首相に就けるため安倍氏は退陣せざるを得ない。
総裁選以外にも首相を続けられない要因はあるので(微小隕石に当たるとか、自民党が分裂するとか、スキャンダルが発覚するとか…)、上記の賭けは総裁選に於ける安倍氏の勝率の下限を示すことになる。
それが最低でも83.3%。
「いや、83.3%は勝率として高すぎるだろう」という人がいれば、今すぐbetfairに参加すれば、期待値がプラスの賭けができる。
裏を返せば、そんな人がいないから、このオッズが残っているというわけだ。

Register-machine can shift graph-coloring from JIT to AOT

There are repeated holy wars at byte-code virtual machine interpreters - stack-machine vs register-machine.

One of the benefits of stack-machines is ease of allocating host machine's register at JIT compilation.
There is a decent assumption that the order of stack element matches access frequency.
Top element of stack has huge access frequency, then next element has next amount of frequency.
So, allocating host's registers from the element of stack top toward below elements of stack eliminates decent amount of memory access by accessing registers instead.

By contrast, it is believed that this scheme can't be applied to register-machines.
Since all virtual registers are symmetric, access frequncy of each register also should be symmetric.
This must be true, if byte-code generators also assume all virtual registers are symmetric.
But, if byte-code generators try creating deflection?

For example, a simplified graph-coloring algorithm from one by famous Gregory Chaitin can do that.
A vertex with N edges in the graph means this vertex can get registers within (N+1)th.
So N+1 regsiters are enough for a graph with vertices with max N edges.
Spilling vertices which have max edges from the graph reduce registers for the graph.
Then we'll get a graph with N registers allocated.
After getting the graph with N registers, we can get the graph with N+1 registers by restoring vertices spilled at time when the graph still contains vertices with N edges.
When we restore back vertices, all these vertices can get (N+1)th register without chainging register allocation for other vertices.
This means the register allocation result from this algorithm is incremental.
Leaving 1st register only and rest registers to spill is same result which this algorithm produces with one register at the beginning.
Then the result with 2nd register restored back is also same with the case there are two registers, and so on.

Under these byte-code generators for register-machine, register allocation at JIT becomes simple and powerful.
Only allocate host's register from 1st virtual register to Nth one in case host machine provides N register.
And you'll get the powerful result from graph-coloring schemes.

-- See also --
The design of the Inferno virtual machine
http://www.vitanuova.com/inferno/papers/hotchips.html
The authors of this virtual machine aim the performance with JIT.
But from tiny benchmarks on my environment, neither Inferno's byte-code generator nor JIT seams to treat register allocation yet.

Combining Offline and Online Optimizations: Register Allocation and Method Inlining
http://pdfs.semanticscholar.org/9a4a/d55afd9159f037aa163cbf4a5a770a49999c.pdf
What I wrote above is called "cumulative register assignment" on this thesis that such researchers visited before.

C言語を学ぶ時に人工知能から入門することがなぜ合理的なのか

個人的な事情により、コンピュータの基礎知識を得る方法を探していたところ、
プログラミングを学ぶ時に人工知能から入門することがなぜ合理的なのか - WirelessWire News(ワイヤレスワイヤーニュース):
https://wirelesswire.jp/2017/08/60921/
を見つけて、なるほどと思った。

仮にそうであれば、これ以上の合理的な入門方法も存在しないと言える。
十分な量の計算資源がある場合、コンピュータの機能は、人工知能のそれの下位互換でしかないからだ。
人工知能でできないことは、コンピュータにもできない。
しかし、コンピュータでできることは全て、人工知能でもできる。

そんなコンピュータより多機能なものへ、コンピュータ自身より先に入門すべきだなんて、常識外れだ。
常識的には、機能が沢山ある分だけ、学ぶことも増える。
多機能なスマートフォンよりも単機能なガラパゴスケイタイを高齢者が好むのは、学ばねばならないことが少なくて済むからだ。
電話をかけることしかできないのだから、フィッシングサイトやExcelウイルスに注意する必要が無い。
しかし上記ウェブページの筆者はこう喝破する。
「しかしキーボードを使ったプログラミングの入門としては、人工知能のプログラミングはかなり簡単な部類です。」

そういえば、そもそも人工知能の難しさとは何だっただろう?
人工知能の最先端を行くIBMGoogleなどを見れば分かる。
Deep Blue、ワトソン、AlphaGO、…。
どれもこれも強力なスーパーコンピュータの上で動くシステムだ。
人工知能の難しさは、要求される資源の量が膨大なことだ。
人工知能をマトモに走らせるには、強力なハードウェアが必要なのだ。
例外は精々、将棋ソフトの思考アルゴリズムを塗り替えたBonanzaくらいだろう。
Bonanza - Wikipedia
https://ja.wikipedia.org/wiki/Bonanza

高性能なワークステーションで参加する者も多い中、Bonanzaは一般向けのノートパソコン (VAIO SZ-90S)、筐体を冷却するのは小型USB扇風機と、低スペックの環境での優勝であった。

この例外こそ、人工知能が強力なハードウェアを欲する理由を説明してくれる。
上記Wikipediaページより「
Bonanza登場以前のコンピュータ将棋では、その局面で可能なすべての指し手を評価する(全幅探索)のではなく、自然な指し手を重視して探索(選択探索)していた。
全幅探索では全ての指し手を評価すると選択肢が膨大になり、現実的ではないと考えられていたからである。
しかしBonanzaはその常識を覆し、全幅探索を採用することで、これまでの他のソフトが見落としていた(あるいは開発者が軽視していた)指し手に高い評価を与えることが可能となった。

人工知能アルゴリズムの基本は、「総当たり探索」なのだ。
人工知能は、究極の理想としては、プログラマから何も教わらなくても問題を解けなければならない。
ノーフリーランチ定理でいうところの「汎用最適化戦略」だ。
ノーフリーランチ定理
https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%95%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%B3%E3%83%81%E5%AE%9A%E7%90%86
「あらゆる問題で性能の良い汎用最適化戦略は理論上不可能であり、ある戦略が他の戦略より性能がよいのは、現に解こうとしている特定の問題に対して特殊化(専門化)されている場合のみである」
この定理によって証明されてしまった膨大な資源要求を何とかしようというのが、人工知能の難しさだ。

逆にノーフリーランチ定理を破ろうとしなければ、ネタ元の筆者が述べたとおり、プログラミングは極めて簡単になる。
究極の人工知能が相手なら、プログラマ人工知能に何も教える必要がないからだ。
勿論、究極の人工知能は未だ製造されておらず、現存するのは人工知能の下位互換でしかないコンピュータだ。
しかし、下位互換なりに恩恵は伝わる…総当たり探索のアルゴリズムは極めて単純だ。
単純なアルゴリズムは複雑なものより効率がいいから、競争相手も人工知能ならバカにできない。
上記Bonanzaのページより「
開発当時の保木は将棋に対する造詣は深くなく、チェスと同じようなものであると考えていた。
そのためコンピュータチェスで一般的な全幅探索を採用したが、保木によると「選択的探索は選択を行う処理が複雑になるため、全幅探索よりも負荷がかかる」としている。


すなわち、計算資源の要求量だけが、人工知能から入門する場合の壁なのだ。
C言語の場合、この点は問題になりづらい。
計算資源の要求を節約する究極の方法はアセンブラしかないが、「高級アセンブラ」の異名を持つだけあって、C言語アセンブラ並みに計算資源を効率よく使える言語のひとつだ。
逆に、C言語人工知能以外から入門するのは、コンピュータ初学者にとって困難だろう。
人工知能以外の分野では、総当たり探索より効率的で、しかし複雑なアルゴリズムが普及していているからだ。
入門の段階で、アセンブラに毛が生えた程度の記述力しかないC言語を使って、そんな複雑なアルゴリズムを記述しなければならない。

変化の激しいコンピュータ業界において、プログラミング言語の栄枯盛衰もまた激しい中、C言語は事実上の業界標準として君臨している。
コンピュータを学ぶ上で、C言語は避けられそうもない。
C言語を学ぶなら、まずは人工知能の実装を目指すよう、勧めたい。

武力攻撃事態を災害より甘く見るな

とある新聞の緊急事態条項に関する記事で、
「災害をダシにするな」
という主張が載っていて気になった。

著者は永井 幸寿。
弁護士だそうで、そのものズバリの本も出している。
憲法に緊急事態条項は必要か (岩波ブックレット) | 永井 幸寿 |本 | 通販 | Amazon
https://www.amazon.co.jp/%E6%86%B2%E6%B3%95%E3%81%AB%E7%B7%8A%E6%80%A5%E4%BA%8B%E6%85%8B%E6%9D%A1%E9%A0%85%E3%81%AF%E5%BF%85%E8%A6%81%E3%81%8B-%E5%B2%A9%E6%B3%A2%E3%83%96%E3%83%83%E3%82%AF%E3%83%AC%E3%83%83%E3%83%88-%E6%B0%B8%E4%BA%95-%E5%B9%B8%E5%AF%BF/dp/4002709450
【国会ハイライト】「災害をダシに憲法を変えてはいけない」~永井幸寿弁護士が憲法審査会で意見陳述!緊急時の国会議員の任期問題は「参議院緊急集会」と公選法「繰延選挙」で対処可能!(前編) | IWJ Independent Web Journal
https://iwj.co.jp/wj/open/archives/370892
では
「災害は事前の準備なくして対策できない」
「災害のあとに国家に権力を集中しても、泥棒を見て縄をなうようなもので、災害対策にはまったく役に立たない」
と主張しているらしい。
似たような主張は、他の弁護士たちにもあるようで、
災害対策のために重要なこと~平常時に準備していないことはできない~[弁護士が見た復興] |  東北復興新聞
http://www.rise-tohoku.jp/?p=10099
緊急事態条項が災害への対処として無力なのは、その通りなのだろう。
ならば、確かに災害は緊急事態条項の制定にとっては「ダシ」に過ぎない。

では、緊急事態条項制定の「本丸」ではどうなのだろう?
すなわち、武力攻撃事態である。
先の永井氏の主張の「災害」部分を「武力攻撃事態」に置き換えてみよう。
「武力攻撃事態は事前の準備なくして対策できない」
「武力攻撃事態のあとに国家に権力を集中しても、泥棒を見て縄をなうようなもので、武力攻撃事態対策にはまったく役に立たない」
違和感を感じないのは
ドイツ電撃戦に学ぶ OODAループ「超」入門 | 夕撃旅団 |本 | 通販 | Amazon
https://www.amazon.co.jp/%E3%83%89%E3%82%A4%E3%83%84%E9%9B%BB%E6%92%83%E6%88%A6%E3%81%AB%E5%AD%A6%E3%81%B6-OODA%E3%83%AB%E3%83%BC%E3%83%97%E3%80%8C%E8%B6%85%E3%80%8D%E5%85%A5%E9%96%80-%E5%A4%95%E6%92%83%E6%97%85%E5%9B%A3/dp/4909400621
の著者のホームページ
http://majo44.sakura.ne.jp/planes/F22/ooda2/904.html

わかりやすい例が同時多発テロです。
一定の地区で、同時に複数のテロ行為を引き起こし、
警察、消防の対応能力を麻痺させ、国家の治安を危機に追い込む、
といったケースですね。

この場合、総理大臣などを最高責任者として、
全ての情報収集と権限が集中した対策本部を立ち上げる、
といったやり方が最悪の対応となります。
この場合、どれほど優秀な人が総理大臣であろうと、
あっという間に無数の情報が個人に集中して速攻でループはパンクします。
そして、通常、総理大臣はそういった能力で選ばれないため、
その対応能力は絶望的であることが普通なのです。

を読んだ、私だけだろうか?

少なくとも、永井氏自身は違和感を感じたのだろう。
「災害と違って武力攻撃事態ならば、事前の準備が欠けてても、緊急事態条項で対策できるかも知れない」
「権力を集中した国家ならば、泥棒を見てから縄をなっても間に合うかも知れない」
とでも思っているからこそ、本丸である武力攻撃事態ではなく、ダシである災害を用いているのだ。
武力攻撃を仕掛ける敵として、件の旧ドイツ軍どころか、現代的なアルカイダや、軽武装大日本帝国陸軍との戦いや国共内戦を戦い抜いた中国共産党すら、想定外なのか?
Wikipedia第二次世界大戦の犠牲者」によると、先の大戦での日本人の戦没者は約240万人とも310万人とも言われているらしい。
一方、1000年に一度と言われる規模である東日本大震災の犠牲者は約2万人に過ぎない。
「災害と違って武力攻撃事態ならば…」なんて、想定が甘いと私は言わざるを得ない。

当然、緊急事態条項を求める、オツムがお花畑な連中については、述べるまでもない。