この記事を一旦書いたあと、重要な追加証言が得られたため、追記修正しています。結論もやや変わっていますが、現時点のほうがより正確です。
ディープラーニングが現在これだけ流行っている1つの要因は、TensorFlowやPyTorchなどのフレームワークが非常に便利だからです。ニューラルネットワークの設計、訓練、そして分類などの推論がフレームワークを使えばとても簡単に行なえます。
普通に使っている人達は、これらのフレームワークを『ツール』あるいは『ライブラリ』だとみなしていると思います。でも実際のところ、これらはプログラミング言語です。より正確に言えば、すべてのディープラーニングフレームワークはディープラーニング計算用DSL（Domain-Specific Language、ドメイン特化言語）と見なせます。このDSLは大抵、Pythonなど他の汎用言語への埋め込み型で定義されています。
これらDSLに共通して言える特徴が微分可能性です。そのDSLで書かれたプログラムは自動で微分できて、その微分の結果に依って内部のパラメータを自動更新できるのです。
あるとき、僕はネット上のどこかで"differentiable programming language"と書いたwebページを見かけました。それがいつだったか、どのサイトだったかははっきり覚えてないのですが、2017年頃だったと記憶してます。
その後、今年チューリング賞も獲ったディープラーニングの父の1人であるYann LeCunがこんな記事をFacebookに投稿しました。2018年1月7日のことです。
OK, Deep Learning has outlived its usefulness as a buzz-phrase.
Deep Learning est mort. Vive Differentiable Programming!
（雑な訳：OK、ディープラーニングはバズフレーズになって、便利なものを遺してくれた。
ディープラーニングはお亡くなりになった。微分可能プログラミング万歳！）
そして、この記事が結構バズりました。
この記事が有名になりすぎたのか、ちょいちょい「LeCunが『微分可能プログラミング』を考えついた」と書いた文章を見かけるようになり、結構戸惑いました。しかもその後、かの Gordon Plotkin（プログラム言語理論研究の大家です）が “Some Principles of Differential Programming Languages”というタイトルの基調講演を、POPL’18という、 プログラム言語理論のトップカンファレンスでしていたのを知りました。この講演が2018年1月初旬。なので、LeCunが起源という噂とは矛盾します。
それで、僕はこのフレーズのオリジナルは何なのかを調べ始めました。折しも今年の3月にPlotkin先生が来日していて、そのおかげで重要なヒントを先生からもらうことができました。
Plotkin先生がこのアイデアを最初に知ったのは2015年のChris Olahのブログ記事だそうです。ニューラルネットと、関数型言語に登場する型システムって実は似てるんじゃない？ といった趣旨の記事なんですけど、そこには"differentiable functional programming language"（微分可能関数型プログラミング言語）というフレーズが登場します。
僕自身が調べて、これ以上前に"differentiable programming"の類の言葉を見つけることはできませんでした。 せっかくなので、Chris Olahにも直接メールを出して、このフレーズは誰かを参考にしたのか聞いてみました。その返事がこちら（もちろん、彼の掲載許可は取っています）。
I'm not aware of any discussion of "differentiable programming" exactly prior to my post, although it's possible there are things I am unaware of.
I do think there were similar ideas floating around. For example, Leon Bottou has a line in this paper drawing analogies between neural nets and list manipulation in LISP.
（雑な訳：私の記事より本当に前に"differentiable programming"の議論をしたものは知りません。私が気づいてない可能性ももちろんあるけど。
似たようなアイデアはいろいろ漂ってたとは思います。Leon Bottouはこの論文で、ニューラルネットとLISPのリスト操作が似てる、と言うようなことを書いています。）
ちなみに、Olahの記事にはYann LeCunもコメントしています。なので、彼は少なくともこの記事は読んでいますね。
その後2016年に、Atılım Güneş Baydinによる"Diffferentiable Programming"と題した講演があったようです。BaydinはOlahの記事を参照しつつ、"differentiable programming"というフレーズを何回も使っています。
さらにこの中ではDavid Dalrympleのエッセイも参照していて、ここでも"differentiable programming"という言葉を使っています。やはり、ニューラルネットと関数型プログラムが似ている、という話を書いています。
彼にもぜひアイデアの起源を聞いてみたいと思ってるんですけど、Twitterのアカウントしか見つからなかった……ので、詳細を聞けるかどうかはまだわかりません。
記事を一旦公開した後、Dalrymple氏と連絡が取れました。色々話を聞くことができたんですが、この件については以下のような証言をしてくれました。
I definitely got the idea from Olah's blog. I also have strong reason to believe LeCun read my essay before popularizing the perspective, and I think it was a substantial influence. But I'd bet LeCun also read Olah's blog already so I don't want to take much credit, except for streamlining the phrase by removing the word "functional".
（雑な訳：私はこのアイデアを間違いなくOlahのブログから得ました。また、LeCunがこれを広める前に私のエッセイを読んだ、と思える強い理由があって、なのでそれなりの影響はあったと思います。でもLeCunはOlahのブログも読んでいただろうし、たくさん手柄を主張したりはしたくありません。ただし、”functional"という単語をそのフレーズから抜いたのは私の影響だと思います。）
その証言をブログで公開していいか、と聞いてみたところ、少しの逡巡があって、以下のコメントも含めてくれ、と頼まれました。
I cited Olah's blog in the manuscript I sent to EDGE.org, but the editors removed the citation with the justification that references to outside works are against the editorial policy of EDGE.org (which prioritizes self-containedness over other intellectual virtues like giving credit where credit is due). Removing the citation then made it seem like I was implicitly claiming novelty in the essay and I regret that.
（雑な訳：私は EDGE.org （注：彼のエッセイが載ったメディア）に送った原稿にはOlahのブログへの参照を入れていましたが、外部の文献を参照するのは EDGE.org の編集方針に反する（必要なクレジットを入れるなど知財面をきれいにするより、自己完結していることに重きを置く）という理由で編集者によって削除されました。削除によって私がエッセイで暗に新規性を主張したかのようになってしまい、後悔しています。）
彼が誠実であろうとすることに、僕は敬意を評します。
ちなみに、Baydinは2018年にサーベイ論文も書いていて、この中で、"differentiable progamming"の提唱者としてChris Olah, David Dalrymple, そして Yann LeCun の3人を挙げています。
と言ったあたりなので、 僕の調べた限りだと、Chris Olahがこのアイデアを思いついた一番最初で、David Dalrympleがそのアイデアから『微分可能プログラミング』（"differentiable programming"）というフレーズを生み出しました。Yann LeCun は起源ではないですが、このアイデアを大きく普及させたのは間違いなく彼の功績です。
記事を書くにあたり、こちらの不躾な質問に快く回答下さった Gordon Plotkin先生とChris Olah、そして David Dalrymple に感謝します。
英語版も書いたよ。 bonotake.github.io
「微分可能プログラミングって昔からある自動微分と何が違うん？」って質問を頂いたのですが、というか割と想定質問だったんですけども、「深層学習の文脈で同じようなものに別の名前をつけた」とか「深層学習を一般化したら昔から自動微分と言われるようなものになった」っていうのが一番近しいのかもしれないです。そんで、深層学習向けに自動微分よりも拡張されたものになっています。
恐らくですが、本文中でも紹介したBaydinらのサーベイ論文を読むのが一番わかり易いかも。
TensorFlowなどのフレームワークが実際back propagationのときにどういう「微分」をしてるか、は↓の「ゼロディー」にめっちゃくちゃ平易に解説してあるので読んでみてください。
本日（というかついさっき）刊行された雑誌『n月刊ラムダノート vol.1, No.2』に記事を寄稿しました。ということで宣伝エントリーです。
この中で、『計算機科学から見たディープラーニング』という記事を書かせていただきました。
この記事を書くことになったきっかけは2つありました。
まず、ラムダノート社長の@golden_luckyさんと雑談している間にこういう話題で盛り上がり、勢いで執筆を依頼された、というのが1つ。
そしてそれと同時期に、ちょうどMLSE夏合宿2019での企画を考えなきゃいけなくて、そのネタ帳代わりに書いたという側面もあります。東大の萩谷昌己先生をお招きすることは先に決まっていて、先生のご専門である理論計算機科学の観点でディープラーニングを捉え直すとどうなるか、みたいなのを、私なりに考えて記事の形式にまとめました。
で、初稿ができたタイミングで、萩谷先生と、あと共同で企画をしたPreferred Networksの丸山宏さんとで原稿を共有したところ、丸山さんが「3人で座談会をしよう」というとんでもない提案をされ、『鼎談：新しいプログラミングパラダイムとしての深層学習』として実現しました。いやぁ、お2人のお相手を務めるのが私でいいのか、とも思いつつ、精一杯やらせていただきました。
で、その鼎談の中で、萩谷先生が発表されたのがこのスライド。私の記事を元に、さらに考察を重ねておられます。
www.slideshare.net
私の記事のキーポイントも、この記事の中で極めて抽象的ですが説明されているので、数学的な抽象論が平気な方はこちらを見ていただければ記事読まなくても大丈夫です。
これじゃわからん、という人は記事買ってください（ニガワラ
まぁこのスライドだけだと当日の参加者以外には不親切すぎるかもしれないので、以降、先生のスライドをかいつまんで、簡単な解説を試みようかと思います。
（繰り返しですが、この説明で難しいと思う人は記事買ってください）
まず、これは一般的なホーアの三つ組（Hoare triple）の説明です。
事前条件P・プログラムc・事後条件Qで構成される三つ組に対し、(i, o) なる二つ組が出てきますが、これはテストケースです。
iが入力、oが対応するテストオラクル。iはPを満たし、(i, o)はQを満たします。
これは今までのソフトウェアだったんですが、ディープラーニング、あるいはディープラーニングを元にした新たなプログラミングの世界Software 2.0はこの枠組みを拡張します。それがこれ。
私が記事の中で書いたのがこの構図です。（なので Imai triple なんて名前がついている。恥ずかしい……）
{P}c{Q}ではなく{P}[c]{Q}となっているのがミソで、真ん中にある[c]はプログラムではなく、プログラムスキーマ（≒特定の要件を満たすプログラムの集合）です。ディープラーニングでは、ニューラルネットワークのアーキテクチャがこれに相当します。
そして更に学習器tが存在していて、tはテストの集合{(i, o)}を与えると、一番良さそうなプログラムcを自動探索して出力します。
これを更に拡張して、{P}[c]{Q}, {(i, o)}, t の3つを定めるメタ戦略mが存在するよね、というのが萩谷先生の考察。
ちゅーことで、このメタ戦略を規定するのが新たな枠組みである Hagiya triple です。
そして現状、このメタ戦略には機械学習エンジニアEの存在も含まれるのでは、という考察。
本来的には、メタ戦略はm(P, Q, {E})と3つのパラメータを持つ関数になるんですが、現状はメタ戦略m(P, Q)とは腕のいいエンジニアの集合{E}を集めることで、この腕のいいエンジニアE達が良さげなネットワークを設計するという、大変属人的でおおよそ科学とは言えないものになっているのでは？というのが萩谷先生の問いかけです。
ディープラーニングを科学にするには、いかにこの{E}を理論的な枠組みで制御可能にしていくべきかが問われます。
いかがでしょう。小難しい話を駆け足で説明したので、どこまで理解していただけたかわかりませんが。
私が書いた記事は、この Imai triple までをかなり平易に説明したつもりのものです。なので詳細はぜひ記事を読んでください（3回目）。
あと誰か、この続きを研究してみませんか？
（お前がやれ？ ごもっとも……）
注：情報幾何の内容に触れるものではなく、ただの今の僕の心境を綴っただけのエントリーです。あしからず。
タイトルは半分誇張です。本当にわかったわけではないですが、かなり理解が進みました。
きっかけは、色々ぐぐってこの解説論文に出会ったからです。
元々下記の本で情報幾何は勉強しかけていたり勉強会に顔を出し始めたりしていたのですが、仕事の合間に自習する時間がなかなか取れず、モヤモヤとしていたのです。いい本だと思うんですけどね、2冊とも。
GWに時間が取れたので休みのうちに勉強したいと思っていたところ、本文が実質30ページ強の程よい長さの入門が出てきたので、丁度良いと。
結局、4節の応用のセクション除いて一通り読みました。4節も読み切る時間と心の余裕が取れてなかっただけなので、このあと読もうと思います。
もちろん、この30ページがさらさらと読めるわけもなく、実際はわからないことだらけな訳ですが……ただ最近、僕が数学書を読むときわざと試していることが、幅優先で理解していくというものです。
数学書って本来、どアタマから読んで、わからない箇所が出てくれば他の文献を当たって手を動かして考えて……とやるのが王道だと思うんですが、これ、無限に時間のある学生ならOKなんですけど、それなりに仕事抱えてる社会人がやるとまず最初の導入の章読み終わるだけで余裕で1ヶ月以上かかったりするんですよ。本論にたどり着く前に半年以上かかったり。
なので最近は、敢えて
というのを心がけています。深堀りするよりまず全体のイメージをつかむことから始めて、わからないことは後で泥縄式に調べていくという方法。
画像の描画を1ドットずつ精緻に描くのではなく、モザイクだらけでもいいから全体をまず描いて、そのあとモザイク内の各タイルを詳細化していく感じ。
英文の長文読解するときに、わからない単語が出てくるごとに辞書引くのは禁忌で、わからないならわからないなりに読み流していくというのがセオリーですが、それと同じです。
ということで、他に記事を書いたりもしつつ（この詳細はいずれ）、4日くらいかけて冒頭の解説論文をだいたい読み終わりました。
情報幾何がどういう構成でどういうことをやろうとしているのか、かなり雰囲気がつかめました。統計多様体とか情報多様体とかがどういうものかもなんとなくわかったし。
というか、解説論文が非常によくまとまっていたのでかなりわかりやすかったです。
ああそうだ、上の解説論文読む前にこの動画見たんだった。
【のんびり解説】統計多様体の超入門！【情報幾何】 #VRアカデミア #005
この動画もすごく分かりやすかったので、しょっぱなのしょっぱなに観るのオススメ。
（ただし、ここで解説されてる多様体は統計多様体という名称のものそのものではない気がします。）
そんで、先の解説論文の further reading なところに以下の本がオススメされてて、Amazonのなか見検索でPrefaceとか目次とか読む限り確かに次に読む本として良さそうだったんで、さっくりポチってしまいました。
Geometric Modeling in Probability and Statistics (English Edition)
これも次にどれだけ読む時間割けるかわからないんですが、ぜひ暇を見つけて読みたいなと思っています。
今年のGWは10連休だっただけに留まらず、珍しく何かに追い立てられたり体調崩していなかったり*1したので、大変充実した休みを過ごせました。
ということで、GWにやったことをここに記す。
【おしながき】
2日ほど。何しに行ったかはお察し。
一方で自分が作業用にしている部屋は散らかりっぱなしである。
自宅で仕事するときに使ってる椅子が古い木の椅子で固く、ずっと座ってると腰とかお尻とか痛くなってぐったりするので、一念発起してまともなオフィスチェアを買いました。家具屋さんに2日通いました。
在庫の関係で配送は再来週。
某雑誌向けに書きました。論文ではなく一般の読み物です。
ディープラーニングに対するエッセイというか考察というかポジショントークというか、そんなもの。詳細が決まったら明らかにします。
以下を参照。 bonotake.hatenablog.com
Differentiable programming, 別名可微分プログラミング。Yann LeCunが発祥だと思っている人が多いのだけども、そうではありません。
これも後日別エントリーにまとめたい。
でも途中気を失っていたので後で一部見直す。
いきなりですが、n月刊ラムダノートが創刊されました。めでたい。
で、この中にある @mametter さん執筆の記事『「コルーチン」とは何だったのか？』に僕はがっつり関わっていました。
後述しますが、僕と彼とのオンラインでのやり取りの中で記事が書き始められ、方針が決まっていった感じです。
なので、出版を記念してそのへんの経緯を振り返り、また僕なりの感想をまとめようかと思います。
……と思ったんですが、改めてやりとりのログを見返してたんですがアホほど膨大な量になっていて、とても全部振り返るのは無理だと悟りました。
なのでざっくりと。
当該の記事と一緒に読まれることを想定していますので、その記事で語られていることの説明はある程度省いています。
数時間前に @mametter さんが草稿を公開↓したので、そちらを読んでくれても構いません（できれば買ってほしいけど）。
目次：
去る2018年11月17日、仕事でPythonコードを書いていた僕が、ついasyncioパッケージ周りでコードを上手く書けないモヤモヤを夜になんとなく愚痴りました。
その中に、async/await で記述されたものを「コルーチン」*1 と呼んでいるらしい、なんかおかしい、という話をちょろっと入れたのです。
翌日の11月18日、僕の愚痴からアヤシイ匂いを敏感に感じ取った @mametter さんが思いをTwitterでぶっぱして、無事炎j……バズります。
外がいい感じで燃え盛る中、僕や @mametter さんがPythonコルーチンに感じ取った違和感はいったい何なのかを探る長い旅がスタートします。
外がいい感じに炎……盛り上がっているさなか、最初に僕らの間で始まったのは、コルーチンが一番最初に活字にて著されたConwayの1968年の論文の読み会でした。
そこから23日までの5日間、とにかく色んな物を調べまくりました。思いつく限り列挙すると、
その他もろもろ。
そいつらを読みながら、コルーチンの定義とその変遷の様子に関してああでもないこうでもないと2人で延々議論していました。
同時に、Pythonコルーチンを使って対称コルーチンを再現してみたりもしていました。（この結果は省略。そのうち紹介するかも。）
そんな感じで、自分たちがなんとなく「これがコルーチンだ」と思っていたものを、適宜事実と照らし合わせて修正、更新、あるいは補強していく作業でした。
70年代以前の論文を短い期間にたくさん読んだのも初めてで、自分たちがしていることをある時期から2人の間で「考古学」と呼ぶようになるのですが、実際、考古学というのはこういう学問なんだろうなと思った次第。
19日に入って、裏側で延々と議論していた内容を反映して、 @mametter さんが今回の記事の草稿に当たるものを書き始めます。 当初は自分のブログに書くためのもので、もっと簡素だったし、ツイートだと書ききれない @mametter さんのポジショントークというか意思表明というかそういうノリのもので、なので @mametter さんの主張が色濃く残っていました。
23日頃を境に一旦その執筆の手は止まり、2人の間で多少話題になったり、PPL*2でなにかの形で発表しようか？ などという検討をしたりはしていたものの、特段の進捗はなくそのまましばらく記事は放置されます。
年が明けて2019年の1月下旬、@mametter さんが書き溜めてあった草稿をラムダノート社長の @golden_lucky さんに見せたところ好評を得たようで、@golden_lucky さんが以前から構想していた雑誌に載せる方向で話が進んだようです（このへんは僕は直接会話に立ち入ってないのでわからない）。そこで記事の執筆も再開されます。
で、再開早々僕が主張したことは、記事の中で「何がコルーチンか／コルーチンでないか」という断定を避けた方がいい、ということでした。
上述の通り元々は @mametter さんのポジショントークだったので当然そのへんは @mametter さんなりの意見が含まれていたのですが、そこを結論として持ってくるより、むしろ僕らが調べた事実に基づいて「コルーチンの定義が揺らいでいる／変遷している」ということだけを述べ、それ以上の判断は読者に委ねたほうがいいと考えました。
結果として記事もそういう方向に軌道修正されたし、実際そうすることでいろんな立場の人がニュートラルに読める内容になり、記事の価値は上がったのではないかと個人的には思っています。
ここからは、完全に僕個人の雑感です。
今回色々見てまず感じたことは、最近の言語は並列・並行にまつわる概念がごっちゃになっているということですかね。 ファイバー、コルーチン、軽量スレッド、future / promise あたりがごちゃ混ぜになってできているように感じます。 実際のところ、このへんを全部区別できる人がどれだけいるんでしょう？
ということで、記事では最終的に「これがコルーチンだ」という断定は避ける形になりました。 ただ、 記事には載せられていないのですが、実は Marlinが「コルーチンが満たすべき基礎的性質（fundamental characteristics）」というものを書いています （Marlin’80）。 それがこれ。
the values of data local to a coroutine persist between successive occasions on which enter it (that is, between successive calls)
（コルーチン内にローカルに存在する値は連続する “call” の間で保持される）
the execution of a coroutine is suspended as control leaves it, only to carry on where it left off when control re-enters the coroutine at some later stage.
（コルーチンの実行は制御が離れたら停止し、その後のどこかでコルーチンに再入したときに制御の離れた箇所から再開する）
カッコ内は僕が今適当に訳しました。明らかな誤訳でなければ微妙なところは見逃して。
これが記事に使われなかったのは、この定義もまた微妙な問題を孕んでいたからです。 どこらへんの解釈かというと “call” です。純粋に考えればコルーチン間の呼び出し／被呼び出しのことでしょう。 つまり、コルーチン間の非同期な呼び出しがあることが前提なんです。
ところが、ここにPythonコルーチンを持ってくると、解釈がとてもややこしくなります。
Pythonコルーチンって、他のコルーチンへの呼び出しで非同期的な中断するわけじゃないんですよね。
呼び出しで非同期的な中断をするのは、呼び出し先のコルーチンか、そいつが呼び出すさらに先のコルーチンか、その先か……がsleepするときだけなんですよ。
呼び出し＝中断の合図ではないんです。
でも、Marlinがこれを著したときにあったのは、対称コルーチンと非対称コルーチンだけでした。 この2つは他のコルーチンを呼び出すことで非同期的な中断をする仕組みで、呼び出し＝中断 なんです。 だからPythonコルーチンはこのMarlinの定義がそのまま当てはまるわけじゃないです。
てか、Pythonコルーチンってぶっちゃけコルーチンというより、仕組みとしてはスレッドに近いんですよね。
sleepで寝て、寝てる間は一緒に動いてる他のスレッドのどれかに制御が移る。sleepが解ければスケジューラによってそのうち制御をもらって処理を再開する。
これ、スレッドなんですよ。
これにfutureの仕組みを足したものがPythonコルーチンの正体だな、と。
ただ、ある想定を置くことで、旧来のコルーチンを使ったモデルと考えられなくもないんです。
それは、スケジューラ（Pythonコルーチンでいうイベントループ）を特別なコルーチンと考えることです。
なのでPythonコルーチンのコンテクストスイッチ（敢えてスレッド用語を使う）は、イベントループがコルーチンを呼び出すことでそのコルーチンが処理を再開する。
sleepすることでイベントループに処理を戻す。
イベントループがresumeして、コルーチンがsleepのタイミングでyieldする非対称コルーチンってことです。
これは、Dahl et al. が大昔に書いている手法で、また、Crystalのファイバーがこういうモデルを採用してたはず。
（僕が他の言語も調べた中で、Pythonコルーチンに一番似てるなと思ったのはCrystalのファイバーでした。）
このモデルを前提に、イベントループ／スケジューラによるコンテクストスイッチを先のMarlinの定義で言う”call”とみなしていいか、という点で 僕と @mametter さんで解釈が分かれて、最終的にこの定義は使えないという話になったのです。
過去の論文や他の言語の仕様も調べまくって色々考えましたが、結局Pythonコルーチンって、個人的にはあまりコルーチンとは呼びたくないんですね、やっぱり。軽量スレッドと呼びたい何かです。
それが悪いというわけではないんですが、ただコルーチンとしてみるとかなり貧弱な機能しかないので、不便です。
中断する際に他のコルーチンを呼び出して、そいつに値を渡すとかできないですからね。
さっきCrystalのファイバーが似てると書きましたが、Crystalは他のファイバーとの非同期な通信機構があります。
Pythonコルーチンにはない。コルーチン間の非同期通信はfutureでやるんです。
Pythonコルーチンは一般的なコルーチンと思うとツラくて、むしろfutureを使った非同期モデルを指向してコードを書くべきなんでしょう。 積極的にfutureオブジェクトを使いまわしていくのがいいのかな、というのが今ん所のPythonコルーチンに対する僕の所感です。
