.
... ぼくのかんがえるすうがくけんきゅうほう
とうだいすうり ますたー 1 ねん
たにむら よしのり
11 がつ 15 にち
. . . .
とある数学徒の若かりし日の記憶
数学徒たるもの、全ての分野に精通しなければ！
そう、数学はひとつ！
俺専用のブルバキを作ってやる！
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 2 / 14
過程
増え続ける膨大なプロジェクト達
中途半端なまま自然消滅していく…
. . . .
結果
遅 れ て い く 勉 強 。
勉 強 し た こ と も 、
結 局 忘 れ て い く 。
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 4 / 14
そんなあなたにおすすめな一冊！
Unix という考え方ーその設計思想と哲学
著者 : Mike Gancarz, 翻訳 : 芳尾 桂 , 出版社 : オーム社
Amazon URL: http://www.amazon.co.jp/dp/4274064069/
. . . .
どんな本なの？
UNIX の個別的な使い方ではなく、
その裏にある考え方や思想が書かれている。
怪しげな自己啓発ではなく、
他の分野にも通ずる汎用性の高い部分を含んだ具体的な方法論。
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 6 / 14
考え方の枠組み
この本で紹介される考え方は次の 9 つの定理 ( 教義 ) に要約される。
Small is beautiful.
一つのプログラムには一つのことをうまくやらせる。
できるだけ早く試作する。
効率より移植性を優先する。
数値データは ASCII フラットファイルに保存する。
ソフトウェアを梃子として使う。
シェルスクリプトによって梃子の効果と移植性を高める。
過度の対話型インターフェイスを避ける。
すべてのプログラムをフィルタとして設計する。
今回はいくつかの理由によって赤で示した 3 つの教義について説明する。
. . . .
Small is beautiful.
大は小を兼ねない。困難は分割するべき。
やたら長い文章やプログラムは誤植やバグを見つけにくい。
定理の証明も一気に証明するより
いくつもの補題や主張に分けた方が見やすい。
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 8 / 14
一つのプログラムには一つのことをうまくやらせる。
文章やプログラムを書く際には、まず何をやりたいかを明確にする。
大きなプログラムは小さなプログラムの総体として設計する。
一般的だがやたら長い文章やプログラムを作らない。
作る際の手間。参照する際の手間。
本題と関係がない上に証明がやたら長くなるような一般化をしない。
使っている条件を明確にするような一般化はむしろ好ましい。
ひとつの証明を知っていれば満足という考え方もあるが、
「どの仮定を足したらどのように証明が簡単にできるか」
を把握するのも重要なこと。
. . . .
定理の理想的な証明
Lemma 1 → obvious.
Lemma 2 → obvious.
Lemma 3 → obvious.
Theorem → By Lemma 1,2,3.
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 10 / 14
できるだけ早く試作する。
事前に考える過ぎるよりまず試しに何か作ってみる！
数学もプログラミングもノーコストで実験できるものが多い！
事件は会議室で起きてるんじゃない。現場で起きてるんだ！
TEX は熱いうちに打て！
人間である以上、事前に完全な予測はできない。
作業を進めていくうちにもっといい方向がみえてくることもある。
プログラムが全て完成してから仕様書の間違いに気付いても遅い。
小さなプログラムを積み重ねて、できる度にテストをするべき。
どんなに美しく見える理論も、具体例が無ければ評価が低い。
多様体上に定義されたなんだかヤバそうな不変量も、
「例えば、S
n
の場合にどうなりますか？」が答えられないと・ ・ ・。
いきなり大定理や大原理を思いつく天才もいるかも知れないが、
多くの場合は膨大な Observation に基づいて発見される。
. . . .
他の教義も一見の価値あり。
みなさんも是非読んでみては？
とうだいすうりますたー1 ねん たにむら よしのり ()ぼくのかんがえるすうがくけんきゅうほう 11 がつ 15 にち 12 / 14
