数理的手法を使いやすくするためのソフトウェア開発

科学技術計算とデータサイエンスについて

MOOC(オンライン講座)のために英語力を向上させるには? (2)

あいかわらず、機械学習のオンライン講座を聴くたびに、英語力不足を感じています。しかし、情報が専門的になると日本語の情報が乏しくなってくるので、英語から逃げてばかりいるわけにはいきません。また、機械翻訳の精度が上がってきたとは言え、すべてのオンライン講座が自動翻訳されて日本語で学べるようになるまで^1待っているわけにもいきません。 そんなわけで、機械学習と並行して、英語学習も再開しました。

STEM領域の英語表現を学ぶことの効果は?

まず、前回ブログでの仮説、「英語でもSTEM領域の基礎を無理なく聞き取れるようになれば、MOOCの学習効率が上がる」に基づいて、

Coursera : English for Science, Technology, Engineering, and Mathematics

を受講して、修了しました。しかし、この講座は簡単すぎました。今でも、Machine Learning with TensorFlow on Google Cloud Platformを理解するために、あいかわらず、ビデオ講義を聞き直しています。(まあ、聞き直す箇所と回数は減ったのかもしれませんが。)つまり、これだけでは十分ではありませんでした。

初級と中級レベルのMOOCで何が違うのか?

そこで、English for STEMに対するML with TF on GCPの違いを考えてみると、次の2つです。

(1) 文が複雑、かつ、早口。 (English for STEM は初級レベルの内容を文法的に簡単で、かつ、短い文で説明していますが、ML with TF on GCPは専門的な内容を長い文で早口で説明しています。)

(2) 背景知識が少ない。(English for STEM の内容はすでに知っていたことばかりですが、ML with TF on GCPの内容には知らなかったことが多いです。)

このうち、(2)については、そもそも、知らなかったことを学ぼうとしているのですから、どうしようもありません。しかし、(1)は英語処理速度と文法理解を向上させることで、対処できるはずです。

もっと速く

それで、英語処理速度の目安として、読書スピードを入門者レベルの英文多読セットでの最後の5冊で測ってみました。平均して毎分138単語で、英語ネイティブの平均である300単語の半分以下でした[^2][^3]。なるほど、この処理速度では、毎分200単語程度で話されているビデオ講義が早口に感じられるわけです。

次に、文法理解力を測るために、Grammar in Use Intermediateの巻末テストを100問やってみると、6割弱の正答率でした。微妙です。。勉強嫌いとしては、文法なんか関係ないと言いたいところです。しかし、文法的な解釈で迷っているようでは、処理速度は上がらないのかもしれません。

そんなわけで、今は、英語処理速度^4 ^5と文法理解^6の向上に取り組んでいます。

参考

1^: オンライン講座は日本語化されていても、理解するためにある程度の英語力が必要なことがあります。例えば、Machine Learning with TensorFlow Google Cloud Platform SpecializationGoogle Cloud Platform Big Data and Machine Learning Fundamentals は、字幕は日本語化されているのですが、ビデオ講義のなかのスライドや音声は英語のままです。

2^: 日本人大学生の平均的な英語読書スピードは毎分80〜100単語で、TOEICのリーディング試験にきちんと全問回答するには毎分150単語以上のスピードが必要なのだそうです

3^: アメリカ人大学生の平均的な読書スピードは毎分450単語ということなので、彼らはビデオ講義を倍速で再生したとしても理解できるわけです。

4^: SSS推薦多読基本セット Elementary Set B エディション:SSS-3B-N

5^: SSS推薦多読基本セット Intermediate Set A エディション:SSS-4A-N

6^: Coursera "Learn English: Intermediate Grammar Specialization" offered by UCI

MOOC(オンライン講座)のために英語力を向上させるには? (1)

英語で機械学習の専門コースを聞くのは、日本語で文学史の専門家から話を聞くのに、似ています。

恥ずかしながら、私には人文系の教養がありません。それで、文学史の話は、日本語であっても、その分野の用語や言い回しを知らないので、さっぱり理解できないのです。 同様に、特徴エンジニアリングの話は、日本語では理解できても、英語では機械学習分野の用語や言い回しに慣れていないので、理解するのに時間がかかります。

いえ、正確に言えば、専門分野に特有の表現に慣れていなくとも問題ないはずです。 むしろ、STEM(science, technology, engineering, mathematics)領域の基礎的な英語表現に慣れていないことが問題なのだと思います。 実際、日本語ではSTEM領域の基礎を話したり聞いたりすることができるので、自分の専門でない分野でも、無理なく学ぶことができます。 しかし、英語ではSTEMの基礎を話したり聞いたりする力がないので、自分の専門である物性物理、生物物理、有機化学くらいしか、すんなりと理解できないのです。

となると、英語でもSTEM領域の基礎を無理なく聞き取れるようになれば、MOOCの学習効率が上がるのかもしれません。

Coursera : English for Science, Technology, Engineering, and Mathematics

研究者あるいはエンジニアの転職

研究者からデータサイエンティストへの華麗な転身^1 で有名なTJOさんが、自身の経験にもとづいて、 転職を考えているポスドクの人たちのために ブログ記事^2をまとめていました。

現役のポスドクだけでなく

その記事は、データサイエンス分野だけでなく、おそらく、 他の理工系分野のポスドクにも役立ちそうです。 そこには、転職前に検討すべきこと、転職の仕方、転職後のサバイバル法 がまとめられています。 おそらく、これから転職を考えているポスドクだけでなく、 すでに転職した元ポスドクにとっても興味深い内容です。 実際、私も元ポスドクで、10年以上前に民間企業へ転職して、 今もその企業で働いているのですが、 非常に感心しました。

なんといっても、長期的な戦略を立てて能動的に行動しているところが素晴らしい。 それに対して、私の転職は、お世話になっていた先生の紹介という受け身であり、 入社後も戦略的というよりも、流されてしまっていることが多いです。反省させられました。

社外あるいは社内での転職のために

しかし、世の中の流れを考えて、仕事の内容を主体的に選び、 そのためにスキルや知識を身につけたり、コネを作ることは、 社外へ転職するためだけではなく、社内で働き続けるためにも必要なのだと思います。 実際、去年から機械学習について学んだ結果として、 社外へ転職してはいないものの、 社内で異動してディープラーニングの高速化に従事することになりました。

こうしてみると、社外転職と社内転職を区別する理由はそれほどないのかもしれません。 そもそも、進歩が指数関数的に加速する世の中では、 科学・工学分野の同じ領域で仕事を続けることは難しくなっています。 なので、その変化に企業が適応しようとするときには、 昔のやりかたに固執する個人は職を失いかねません。 そうならずに働き続けるためには、 社内転職するくらいの準備が必要です。 他方では、その変化に個人が適応しようとしているときに、 昔のやりかたに固執する企業に未来はありません。 そんな企業と心中しないためには、社外転職するための準備が必要です。 そして、どちらの場合でも、個人として準備すべきことは、 将来の変化を見越して、次の仕事を選び、そのために学んでおくことなのだと思います。

時代の流れ

それにしても、自分が企業に就職したときと比べると、 研究者やエンジニアの雇用状況は良くも悪くもすっかり変わってしまいました。 悪いことというのは、アカデミアでの雇用が博士過程進学者が減少するほどに 厳しくなってしまったことです。かといって、民間企業はもはや終身雇用を保証できなくなっています。 しかし、良いことととして、科学・工学分野の進歩と、その産業界への波及の両方が速くなったお陰で、 新興分野でのスキルと学識を持っている人たちは好条件で職を得やすくなっています。 ですから、総合的には希望の持てる状況だと思います。

参考

^1:六本木で働くデータサイエンティストのブログ: 2012年春の転職活動について:研究者→民間企業

^2:六本木で働くデータサイエンティストのブログ: 企業に移って5年が経ちました

テクノロジーを民主化するには、ソフトウェア開発の民主化から

グーグルなどの言う「機械学習民主化^1 ^2 が文字通りの意味ならば、彼らが目指しているのは、 多数の機械学習エンジニアが、多数の人々の利益のために、 という理想だと思います。 これに対して、現実では、 少数のエンジニアリングを理解しない人々が、少数の人々の利益のために、 ということが起こりがちです。 この理想と現実のギャップを解消することは可能なのでしょうか?

テクノロジー民主化するために

民主化といえば、 リンカーンのゲティスバーク演説 ^3

「人民による、人民のための、人民の統治」

のフレーズが有名です。これにならえば、テクノロジー民主化とは、

「エンジニアによる、エンジニアのための、エンジニアリング」

ではないでしょうか。

リンカーンのフレーズは、フランス革命アメリカ建国によってどのような問題が解決されたかを示しています。問題とは、統治のありかたが、貴族や専制君主によって、人民には不利益が生じるようなかたちで、決定されていたことです。 同様に、テクノロジー民主化が解決するであろう問題とは、 エンジニアリングのありかたが、 エンジニアリングを理解しない人々によって、 エンジニアリングから不利益が生じるようなかたちで、決定されていることです。

ソフトウェア・エンジニアリングを理解しない人々によるエンジニアリング

例えば、日本の家電メーカーには次のような問題があります。

日本経済新聞「日の丸家電、打倒アップルの条件 ソフト重視へ転換せよ」中島聡^14

魅力的なソフトウエアを作り出すための全体仕様(アーキテクチャー)を設計することは、机上だけでは決して不可能だ。シェフが実際の料理を作りながらレシピを作るのと同様に、設計を担当するエンジニア自らがプログラムを書き「作っては壊し」の過程を経てはじめてよいアーキテクチャーを作ることができる。

アップル・アマゾン・グーグルをはじめソフトで勝負をしている企業は、どこもそうした開発体制をとっている。...

一方、日本のメーカーでは自分自身がプログラムを書いたこともない幹部候補生が頭の中だけでソフトを設計し、プログラミング作業は子会社に丸投げしている。...

ここで問題なのは、プログラミングを理解しない人が、 ソフトウェアの設計をして、プログラミングのありかたを決めていることです。 こうして、生み出されるソフトウェアに競争力がないために ^4 、利益率が低くなり、エンジニアの待遇は悪くなっています ^5

そして似たような問題は、伝統的な計算科学分野にもあります。

この分野では、ソフトウェア開発のありかたを決めている人々は ハードウェアについては十分に理解していますが、ソフトウェア開発についての理解はそれほどではありません。 そのために、新しい分野で Fortranのような時代遅れの言語は使われなくなり、 言語も開発手法も新しくなっているのとは対象的に、 伝統的分野では、 未だにFortranで書かれた「秘伝のタレ」を、 フォートラン時代の手法で守っています。 その結果、前時代的な日本発の計算科学アプリケーションは 近代的スタイルで開発された 海外発のアプリケーションとの競争に敗れ、 今や、日本国内ですら、海外発の計算科学シミュレーションが 多く使われています。

ソフトウェア・エンジニアリングを理解する人々によるエンジニアリング

日本に比べて、 アメリカのソフトウェアが高い競争力を持っているのは、 ソフトウェア開発者を理解している人々がソフトウェア開発のありかたを決めているからです ^4

そこには、プログラミングを理解しない人が、 プログラミングのありかたを決めてしまうという愚行はありません。 また、フォートラン時代のプログラミングしか知らない人が、 古い開発言語や手法を若い人々に強要するという蛮行もないのです。

このようなソフトウェア開発の民主化によって、 機械学習民主化も実現されつつあります。

具体的に言うと、 昔は、機械学習のアプリケーションプログラムを書くときに、 CやC++でゴリゴリと書いていたのが、 まず、C++Pythonで包み込んだライブラリやソフトウェアフレームワークが普及して、 scikit-learn ^6 などで python スクリプトによって楽にアプリを開発できるようになりました。 そのうちに、TensorFlow ^7 , Chainer ^8 のようにニューラルネットワーク記述のための 領域特化言語が埋め込まれたフレームワークが出てきて、更に楽になりました。 そして、今では、クラウド機械学習 ^9 ^10 ^11 が提供されて、 アプリ開発はプラモデル並みの気楽さになりつつあります ^12 ^13

これに対して、日本の計算科学分野では、ソフトウェア開発が民主化されていないので、 FortranやCでゴリゴリと書くしかなく、 そのような前近代的なプログラミングスタイルには、 オブジェクト指向フレームワークや領域特化言語を使うことによる 素早さや楽しさはありません。

このように、ソフトウェア開発のありかたが、 フォートラン時代なのか近代的なのかによって、 生み出されるソフトウェアやテクノロジーの競争力はまるで違ってきます。

数理的手法を民主化する鍵は、ソフトウェア開発の民主化

以上のように見ていくと、アメリカで機械学習や科学シミュレーションといった数理的手法 が民主化されつつあるのは、ソフトウェア開発が民主化されていたからだと思います。 近代的なソフトウェア開発手法や、 ソフトウェア部品を利用するというプログラミングスタイルが広まっていたからこそ、 大勢の人々がテクノロジーのアプリケーション開発に参加することができ、 その利益が大勢の人々に分配されるのです。

対照的に、日本では、数理的手法に基づくテクノロジー分野において、 ソフトウェア開発が民主化されていないために、 ソフトウェアの生産性と競争力は低く、 その利益率も低いままです。

このように、経済的な利益からいえば、民主化したほうが良いのに、 日本のソフトウェア開発が民主化されないのは、なぜなのでしょうか?

私はそれは、前近代的な手法であっても、日本経済がそこそこ回っていて、 エンジニアの不満は高まってきてはいても、 爆発するレベルには到達していないからだと思います。 私も、米国企業が知識集約型のビジネスモデルで 高い利益率を達成しているを知り、 日本企業が労働集約型のビジネスモデル ^4 で低い利益率に甘んじているのを苦々しく思いながらも、 勤務先を変えてはいません。

しかし、国や企業が破綻する兆候が見えてくると、 そうも言ってられません。


参考

^1:Quara "Why is it important to democratize machine learning?"

^2:なぜ、機械学習の民主化は重要か?

^3:ゲティスバーク演説 - wiki

^4:gihyo.jp » Software is Beautiful » 第3回 なぜ日本のソフトウェアが世界で通用しないのか

^5:ITエンジニアの地位とは?国別、職種別の年収比較

^6:scikit-learn

^7:TensorFlow

^8:Chainer

^9:Amazon Machine Learning

^10:Machine Learning - Microsoft Azure

^11:Google Cloud Machine Learning at Scale | Google Cloud Platform

^12:Gigazine「Googleが自社で使っている「クラウド機械学習」を一般に開放、こんなスゴイことが簡単にできる」

^13:Cloud Vision APIの凄さを伝えるべくRasPi botとビデオを作った話

^14:日本経済新聞2014/01/15「日の丸家電、打倒アップルの条件 ソフト重視へ転換せよ」中島聡

なぜ、機械学習の民主化は重要か?

この質問に対して、 Googleのデープラーニング研究者(でKeras開発者)であるChollet氏は、 2つの理由を答えています^1

(Quara “Why is it important to democratize machine learning?"への回答の要約)

ひとつは、機械学習からなるべく大きな価値が生み出されるようにするためです。 そのためには、機械学習を研究したり、あるいは、使いこなすだけの意志と知性を もっている人であれば、誰でも、 機械学習の知識やツールにアクセスできるようにする必要があります。

もうひとつは、機械学習によってなるべく大勢の人々が豊かになり、 社会全体が安定するようにするためです。 ただ、近い将来には、これから生み出される仕事や利益は 機械学習サービスを開発している人々(や企業)に集中していきそうです。 ですから、そのような富と力の集中を緩和してバランスをとるために、 機械学習による価値の創造に大勢の人が参加する必要があるのです。

^1:Quara “Why is it important to democratize machine learning?”

機械学習・ディープラーニングのこれからの進展

松尾先生の「人工知能は人間を超えるか」^1を読んで、

  • (1)機械学習・デープラーニングの何がブレークスルーなのか?
  • (2)これから成長するのはどの分野か?

をまとめて、

  • (3)どんな仕事が求められるのか?

を考えてみました。

(1)機械学習によるブレークスルー

これまでの人工知能ブームでは、2つの課題を解決できなかった。

  • 第1次ブーム : 推論、探索

    • 課題1: 迷路などの簡単な問題は解けても、チェス、将棋などでは組み合わせが莫大すぎて、探索しつくすことができないので、解けない。
  • 1回目の冬の時代

    • 現実の問題は、計算機に解かせるには複雑すぎる。
  • 第2次ブーム : エキスパートシステムで計算機に「知識」を入れる。

    • 課題2: 「知識」を書きだそうとすると、どこまで書いても書ききれない。
  • 2回目の冬の時代

    • フレーム問題 : 計算機がタスクを実行しようとすると、計算機は適切な「知識」の範囲を選び出すことができない。「知識」の範囲が狭すぎて失敗するか、あるいは、範囲が広すぎて計算時間が足りなくなる。
    • シンボルグラウンディング問題 : 計算機は「モノ」を抽象化した「記号」は扱うことができる。しかし、「モノ」と「記号」を結びつけることができない。それは「意味」が分かっていないから。

課題1の解決 -- チェス世界チャンピオンとプロ棋士に計算機が勝利

  • 機械学習

    • 論理的推論ではなく統計的推定 : 過去の膨大な棋譜という「ビッグデータ」の活用
    • 良い特徴量の発見 : 将棋の盤面を評価するときには、「2つの駒の関係」だけでなく、「3つの駒の関係」を使う。
  • 弱点

    • 良い特徴量は計算機でなく人間が見つけねばならない。

課題2を解決する目処がつき、機械学習の弱点は克服されつつある

  • 「現実からどの特徴を取り出すか」を人間でなく計算機にさせることができれば、これまでの難問はすべて解決できる。
  • ディープラーニングというブレークスルー : 特徴表現学習
    • 計算機がデータから着目すべき特徴を見つける --> 機械学習の弱点は克服される
    • 計算機が特徴を見つけ出して、その特徴で抽象化されている「モノ」との対応関係を取り出すことができれば、その対応関係が「モノ」の「意味」であり、現実の「モノ」を抽象化された「記号」である特徴と結びつけることができる。 --> シンボルグラウンディング問題の解決
    • 計算機はデータから特徴を取り出すことができるのだから、その特徴がタスクをこなすために必要な範囲の情報となる。 --> フレーム問題の解決

次の課題を解けるか、それとも、3回目の冬の時代か?

  • 課題3 : マルチモーダルな抽象化、時系列データからの文脈抽出
    • 画像・音声・圧力データを連携させることで、計算機に感情を認識させられるか?
    • 生物は視覚・聴覚・触覚を連携させて生きている。
    • 動画をばらばらの画像としてではなく、文脈を持つ時系列として認識させることができるか?
  • 課題4 : 行動と結果の抽象化
    • 機械自身の行為とその結果を、あわせて抽象化できるか?
  • 課題5 : 外界との相互作用の抽象化
  • 課題6 : 言語理解・自動翻訳
  • 課題7 : 知識獲得

(2)成長分野

これまで

  • 課題1の解決
    • チェス、将棋、碁

現在の注目分野

  • 課題2の解決 : データから良い特徴量を自動的に抽出

これからの成長分野

  • 課題3の解決 : マルチモーダルな抽象化
    • 環境認識、行動予測、感情理解
    • 「ペッパー」のようなロボットに接客をさせる。
    • 街中の画像、音声センターからのデータを連携させて、防犯・防災に役立てる。
  • 課題4の解決 : 行動と結果の抽象化
    • 自律的な行動計画
      • 自動運転
      • 物流でお客さんに渡すところまで
      • 農業の自動化

(3)これから求められる仕事

  • 課題3の解決 : 種類の異なるセンサーからのデータ収集と予測モデルの連携
    • IoT組み込みデバイスからのデータ収集と解析
    • 収集したデータによる機械学習、学習させてモデルによる予測、デバイスへのフィードバック
    • データ収集、解析、予測をクラウドで統合

???


参考

^1:「人工知能は人間を超えるか (角川EPUB選書)」松尾 豊 (著)

すごいプログラミング言語Formura で、たのしく科学シミュレーション?

科学シミュレーションのプログラミングは、 しばしば、退屈でめんどうなことがあります。

まず、退屈なのは、 ひとそろいの偏微分方程式で記述できるようなシミュレーションであっても、 長大で冗長なソースプログラムを書かねばならないことです。 そして、めんどうなのは、 微分方程式の意味とハードウェアアーキテクチャから どのように高速化すれば良いのかが明らかなときでも、 その機械的なチューニング作業をコンパイラではなく 人間がせねばならないことです。

新しいプログラミング言語

しかし、こうした冗長性と機械的作業を解消するための 研究も行われています ^1 ^2 ^3 ^4 ^6 ^7 。 こうした研究は理化学研究所でも進められおり ^5 、 その論文 ^7 は、 スーパーコンピューティングの国際会議"SC16"において、 ゴードンベル賞のファイナリストに選ばれました ^9

論文 ^6 ^7 は、新しいプログラミング言語 Formura について書かれています。 この言語は、 Fortran が初等的数式を実行形式のコードへと変換するように、 偏微分方程式をCのコードへと変換します。 そして、偏微分方程式で、例えば、菌類の地下ネットワークをシミュレートしようとすれば、 FortranやCでは長大なソースプログラムを書かねばなりませんが、 Formuraならたった20ステップ!ですみます。 また、そのチューニング作業を人間が行わずとも、 コンパイラによる自動チューニングだけで、 理研スパコンから1.2ペタプロップスの性能を引き出せるのです。

楽しいプログラミングだけですごいのか?

さて、こうした研究は科学シミュレーション分野を変えていくのでしょうか? たしかに、プログラミングから冗長性と機械的作業が減れば、 それだけプログラミングは楽しくなります。 しかし、楽しさに現実を変える力はあるのでしょうか? ちなみに、Formura論文の筆頭著者の村主さんは、 「すごいHaskell、たのしく学ぼう」 ^8 の訳者のひとりでもあり、 私はこの本を途中まで読んでみて、 関数型プログラミングには、シミュレーションプログラミングにつきものの冗長性と機械的作業を 解消し、プログラミングを楽しくできる可能性があると知りました。 ただ、Haskellのような関数型プログラミング言語やその楽しいプログラミングスタイルを、 自分の仕事である数理的手法のソフトウェア開発に使える可能性は小さいと判断し、 このすごい本を途中で読むのをやめてしまいました。

関数型プログラミングと領域特化言語はすごい

しかし、私の判断は間違っていたのかもしれません。 プログラミング言語Formura は、Haskellで実装された独立型の領域特化言語 ^10 ^12 であり、 関数型プログラミングの楽しさが科学シミュレーション開発のやり方を変えうることを示している と思います。 また、Formuraの研究の前に、Haskellで実装された埋込み型の領域特化言語 Paraiso ^4 も、 関数型プログラミングが、シミュレーションをプログラミングしやすくするだけでなく、 その計算速度をも向上させられることを 示しています。

やはり、関数型プログラミング、それによるメタ言語的抽象 ^11 と領域特化言語は素晴らしいです。


参考

^1:Klaus Iglberger, Georg Hager, Jan Treibig, and Ulrich Rüde, "Expression Templates Revisited: A Performance Analysis of Current Methodologies", SIAM J. Sci. Comput., 34(2), C42–C69.

^2:Pierre Esterie, Joel Falcou, Mathias Gaunard, Jean-Thierry Lapresté, Lionel Lacassagne, "The Numerical Template toolbox: A Modern C++ Design for Scientific Computing", Journal of Parallel and Distributed Computing, Elsevier, 2014, 74 (12), pp. 3240-3253.

^3:Christophe Prud'Homme, Vincent Chabannes, Vincent Doyeux, Mourad Ismail, Abdoulaye Samake, Gonçalo Pena, Cécile Daversin, Christophe Trophime, "Advances in Feel++: a domain specific embedded language in C++ for partial differential equations",Eccomas'12 - European Congress on Computational Methods in Applied Sciences and Engineering, Sep 2012, Vienna, Austria

^4: T. Muranushi, “Paraiso: an automated tuning framework for explicit solvers of partial differential equations,” Computational Science & Discovery, vol. 5, no. 1, p. 015003, 2012.

^5:理化学研究所プレスリリース「式が書ければ「京」が使える-高度なプログラムを自動生成できる新言語「Formura」を開発-」

^6:Takayuki Muranushi, Seiya Nishizawa, Hirofumi Tomita, Keigo Nitadori, Masaki Iwasawa, Yutaka Maruyama, Hisashi Yashiro, Yoshifumi Nakamura, Hideyuki Hotta, Junichiro Makino, Natsuki Hosono, Hikaru Inoue, "Automatic generation of efficient codes from mathematical descriptions of stencil computation", FHPC 2016: Proceedings of the 5th International Workshop on Functional High-Performance Computing

^7:Takayuki Muranushi, Seiya Nishizawa, Hirofumi Tomita, Keigo Nitadori, Masaki Iwasawa, Yutaka Maruyama, Hisashi Yashiro, Yoshifumi Nakamura, Hideyuki Hotta, Junichiro Makino, Natsuki Hosono, Hikaru Inoue, "Simulations of below-ground dynamics of fungi: 1.184 pflops attained by automated generation and autotuning of temporal blocking codes", SC '16 Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis Article No. 3

^8:「すごいHaskell、たのしく学ぼう」Miran Lipovaca (著), 田中 英行 (翻訳), 村主崇行 (翻訳)

^9:Finalists Compete for Prestigious ACM Gordon Bell Prize in High Performance Computing

^10:M.Fowler and R.Parsons, "Domain-Specific Languages", Addison-Wesley, 2011.

^11:Structure and Interpretation of Computer Programs 2nd edition

^12:"Functional Programming for Domain-Specific Languages", Central European Functional Programming School Volume 8606 of the series Lecture Notes in Computer Science pp 1-28.