Gauche/Scheme を勉強する（三度目の正直）

過去二回挫折した Gauche/Scheme の勉強を再開したいと思う。

www.thekingsmuseum.info

www.thekingsmuseum.info

今までは少しストイックに勉強しようとしすぎて挫折してしまったきらいがあるので、ゆるく進めていこうと思う。

ついでに、Evernote にまとめたメモも載せていこう。

１章: Lisp と Scheme

• LISP: 数式処理向けに開発
  • LISt Processing
• 「リストで表現されたプログラム」を受け取って、それを解釈する
• S 式
  • 基本要素、もしくは、S式を並べて括弧でくくったもの
  • 例
    • 1 は数値ひとつの S 式
    • * は記号ひとつ S 式
    • (* 2 3) は記号*、数値2、数値3からなる S 式
• プログラムとして S 式を次のように解釈
  • (<手続き> <引数> <引数>, …)
  • ⇒ もともとはデータ形式。プログラムとしては M 式があった
• Scheme はシンプルな言語仕様で組み立てた
  • lambda 式は、「レキシカルな環境を保持した手続き」（クロージャ）へと評価される
  • 手続き呼び出しは継続を伴った引数付き goto である
• Scheme プログラマは抽象構文木を扱える

2章: Gauche の特徴

• 手軽にプログラムを書いて試せるスクリプト処理系
• 実用規模のプログラムまで、機能、性能でスケールする
• 他の言語のアプリケーションに埋め込み可
• ネイティブ binding もある

3章: Gauche の設計思想や誕生の背景

• Perl からの影響
  • 正規表現リテラル
  • 文字列補間
  • モジュールシステム
  • DBI/DBD
• Common Lisp からの影響
  • キーワード引数
  • オブジェクトシステム
  • コンディション

プログラミングGauche

『失敗の本質 - 日本軍の組織論的研究』を読んで

久しぶりの投稿。というか今年初投稿だ…。

失敗の本質―日本軍の組織論的研究 (中公文庫)

日本軍の失敗の本質は『陸軍の白兵戦思想』と『海軍の艦隊決戦』という過去の成功体験から逃れられず、組織が過度に適応してしまい、変わりゆく環境に適応できなくなってしまったことにある。

本書の言葉を借りれば

適応は適応能力を締め出す

ということ。

全体としてちょっと冗長で読みにくかったかな。 戦史って文字で読んでも全然頭に入ってこないね。

あと、漫画のジパングでよく見た人物がよく登場した（当たり前）。 ジパング読んでた時にはあまり理解してなかったけど、この本を読んで、大本営、参謀本部、軍令部、陸軍省、海軍省あたりの違いが理解できた。

ジパング（１） (モーニングコミックス)

寄付

ちょっとしたきっかけで毎月一定額を寄付してる。

寄付先は World Food Programという団体。

理由は、

学校で給食が出るようになると、親にとっては子供を学校に行かせる大きなモチベーションになる

という話を聞いて「なるほど〜」と思ったから。

この世界をよくするためには教育が重要だと思いますので。

よもやま話

WFP には本家団体と日本の代理店的な団体がある。

• World Food Program (本家)
• 国連WFP協会 (公式代理団体)

日本の代理団体の方に寄付すれば税制上の優遇措置がうけられる。 一方、寄付額の 1/4 くらいは日本での活動費として使われるため、実際には寄付額の 3/4 しか寄付先には渡らない。

それを元に日本で活動することで日本企業からの大口の寄付を呼び込めたりするわけだから、意味のある費用だとは思う。 でも、自分の寄付がなるべく直接活動に使われた方が嬉しいなぁ、と思って本家に寄付してみてる。

たしか寄付額の 93% がそのまま活動に使われる、と書いてあった。

月数千円からできるので、ぜひあなたも寄付してみてはいかがでしょうか。

http://www1.wfp.org/donate-now

小さく理解する

ちょっと必要があって Tensorflow.js を勉強している。

Tensorflow のようなボリュームのある新しいフレームワークを目の前にすると、わくわくする気持ちがある反面、「自分には理解できるのだろうか」という不安にかられる。

その不安を前にどうするか。

少し前までは、一度に大きなことを理解しようとしてうまくいかないことが多かった。結果として「とりあえず動くものを作る」という方法で不安を解消しようとする。でも、この方法では不安は解消されない。なぜなら、結局のところ対象を理解していないから。

最近は「小さく理解する」ことでこの問題が劇的に改善した。

必ず、シンプルで悩まずとも理解できるようなコードから始める。そうすると「自分でも理解できるんだ」という小さな自信が芽生え、安心感が得られる。難しい問題に出会ったとしても蓄積した自信と安心感によって、挫けることが少なくなる。挫けることが少なくなると、理解できる可能性がずいぶんと高まる。

「小さく理解する」というツールはここ最近の自分にとって欠かせないものになった。

Tensorflow.js は、このページから始めるのが「小さく理解する」のにちょうどよかった。

https://js.tensorflow.org/tutorials/core-concepts.html

// 2x3 Tensor
const shape = [2, 3]; // 2 rows, 3 columns
const a = tf.tensor([1.0, 2.0, 3.0, 10.0, 20.0, 30.0], shape);
a.print(); // print Tensor values
// Output: [[1 , 2 , 3 ],
//          [10, 20, 30]]

これなら僕にも理解できるからね。

Coursera: Convolutional Neural Networks を修了したよ

Coursera: Deep Learning Specialization の Course 4: Convolutional Neural Networks を修了しました。

内容としては次の通り。

• Convolutional Neural Network (CNN)
  • Convolution
  • Edge Detection
  • Padding & Stride
  • Pooling
• Network Architecture
  • LeNet-5
  • AlexNet
  • VGG 16
  • ResNet
  • Inception Network
• Object Detection: YOLO Algorithm
  • Object Localization
  • Sliding Windows
  • Intersection Over Union (IOU)
  • Non-max Suppression
  • Anchor Box
• Face Recognition
  • Verification vs Recognition
  • One Shot Learning
  • Siamese Network
  • Triplet Loss
• Neural Style Transfer
  • Content Cost Function
  • Style Cost Function

こうやって書いてみると四週間でなかなか頑張ったじゃないか、という感じ。 かといって毎週毎週量が多くて大変、ということはなく、楽しく勉強できたなーって思った。

ただ、今回のコースは今までと違って「さわりだけ押さえておく」って感じで、実務で使いたければもう少し勉強しないとだめかなーって印象。 でも、その「もう少し勉強するための下地」は身についた感じがあって、あとは必要に応じて教科書とか論文を読めばなんとかなりそう。

次は最後のコースで RNN。いろいろの都合で6末開始になりそうだなぁ。

Coursera: Structuring Machine Learning Projects を修了したよ

Coursera: Deep Learning Specialization の Course3: Structuring Machine Learning Projects を修了しました。本当は1ヶ月くらい前に終わってたけど…。

内容としては次の通り。

• Machine Learning Strategy
• Orthogonalization
• Evaluation Metrics
• train/dev/test distribution
• Comparing human level performance
• Error Analysis
• Transfer learning/Multi-task learning
• End-to-end deep learning

今回のコースはかなり実践的な内容で「AI プロジェクトはこうやって進めましょう」というような話がメイン。こういう実践的な内容はこの講義でしか受けられないんじゃないかなーと思った。

単一の Metrics を設定するとチームパフォーマンスが高まる、プロジェクトは iterative だからからシンプルなモデルをまずは実装しましょうとか、最初に Error Analysis をしましょう、とか。AI プロジェクトに限らないといえばその通りだけど。

Deep Learning はハイパーパラメータが特に多い中で、どのハイパーパラメータがどの Metrics を改善・悪化させるかを意識するのはとても重要。この講義ではそれを昔のテレビのチューニングノブに例えていた。複数のノブを同時に操作してしまうと、何が起きているか分からなくなってしまうので、どのノブがどんな影響を持っているか正しく把握して、それぞれ個別に操作していきましょう、という話だった。

Dependencies - The Twelve-Factor App

12 Factor App シリーズ。2個目は依存関係の管理について。

Dependencies: The Twelve-Factor App

パッケージマネージャ

12 Factor app は決してライブラリに暗黙的に依存しません。

プログラミング言語にはライブラリを管理するためのパッケージマネージャが存在します。

システムワイド (site-package) にもインストールできますし、app を含む特定のディレクトリだけにインストールすることも可能です (vendoring or bundling) が、決して site-package にインストールするようなことがあってはいけません。

ツールへの依存

OS 側のツールにも暗黙的に依存してはいけません。

たとえば暗黙的な ImageMagick や curl の存在には依存してはいけません。 すべてのシステムに存在することや適切なバージョンが存在することを保証できないからです。

もし、ツールが必要であれば明示的に依存関係を書かなければなりません。

依存関係宣言と依存関係分離

すべての依存関係は依存関係宣言を使って明示的に宣言されます。 また、app の実行時には依存関係分離ツールを使って依存関係がシステムに漏れ出さないようにしなければなりません。

これは開発環境にもプロダクション環境にも適用されます。

具体例

Ruby では依存関係宣言のために Gemfile を利用し、依存関係分離のために bundle exec を利用します。

Python では依存関係宣言のために Pip を利用し、依存関係分離のために Virtualenv を利用します。

たとえ C 言語であっても依存関係宣言に Autoconf を利用し、依存関係分離のために静的リンクを利用できます。

たとえツールが何であろうと、依存関係宣言と依存関係分離はは常に一緒に行う必要があります。