TA小話 2013 11 15 ぼくのかんがえるすうがくけんきゅうほう(UNIXという考え方)

13 

Loading....

Loading....

Loading....

Loading....

Loading....

全文

(1)

.

...

ぼくのかんがえるすうがくけんきゅうほう

とうだいすうり ますたー 1ねん たにむら よしのり

(2)

. . . .

とある数学徒の若かりし日の記憶

数学徒たるもの、全ての分野に精通しなければ! そう、数学はひとつ!

俺専用のブルバキを作ってやる!

(3)

過程

増え続ける膨大なプロジェクト達

(4)

. . . .

結果

遅 れ て い く 勉 強 。

勉 強 し た こ と も 、

結 局 忘 れ て い く 。

(5)

そんなあなたにおすすめな一冊!

Unix

という考え方ーその設計思想と哲学

著者: Mike Gancarz,翻訳: 芳尾 桂,出版社: オーム社

(6)

. . . .

どんな本なの?

UNIXの個別的な使い方ではなく、

その裏にある考え方や思想が書かれている。 怪しげな自己啓発ではなく、

他の分野にも通ずる汎用性の高い部分を含んだ具体的な方法論。

(7)

考え方の枠組み

この本で紹介される考え方は次の9つの定理(教義)に要約される。

Small is beautiful.

一つのプログラムには一つのことをうまくやらせる。

できるだけ早く試作する。

効率より移植性を優先する。

数値データはASCIIフラットファイルに保存する。 ソフトウェアを梃子として使う。

シェルスクリプトによって梃子の効果と移植性を高める。 過度の対話型インターフェイスを避ける。

すべてのプログラムをフィルタとして設計する。

(8)

. . . .

Small is beautiful.

大は小を兼ねない。困難は分割するべき。

やたら長い文章やプログラムは誤植やバグを見つけにくい。 定理の証明も一気に証明するより

いくつもの補題や主張に分けた方が見やすい。

(9)

一つのプログラムには一つのことをうまくやらせる。

文章やプログラムを書く際には、まず何をやりたいかを明確にする。 大きなプログラムは小さなプログラムの総体として設計する。 一般的だがやたら長い文章やプログラムを作らない。

作る際の手間。参照する際の手間。

本題と関係がない上に証明がやたら長くなるような一般化をしない。

使っている条件を明確にするような一般化はむしろ好ましい。

ひとつの証明を知っていれば満足という考え方もあるが、

「どの仮定を足したらどのように証明が簡単にできるか」

(10)

. . . .

定理の理想的な証明

Lemma 1

obvious.

Lemma 2

obvious.

Lemma 3

obvious.

Theorem

By Lemma 1,2,3.

(11)

できるだけ早く試作する。

事前に考える過ぎるよりまず試しに何か作ってみる!

数学もプログラミングもノーコストで実験できるものが多い!

事件は会議室で起きてるんじゃない。現場で起きてるんだ!

TEXは熱いうちに打て!

人間である以上、事前に完全な予測はできない。

作業を進めていくうちにもっといい方向がみえてくることもある。

プログラムが全て完成してから仕様書の間違いに気付いても遅い。

小さなプログラムを積み重ねて、できる度にテストをするべき。

どんなに美しく見える理論も、具体例が無ければ評価が低い。

多様体上に定義されたなんだかヤバそうな不変量も、

「例えば、S

n

の場合にどうなりますか?」が答えられないと・・・。

いきなり大定理や大原理を思いつく天才もいるかも知れないが、

(12)

. . . .

他の教義も一見の価値あり。

みなさんも是非読んでみては?

(13)

Remark

Updating...

参照

Updating...

関連した話題 :