2012/03/18
ハイポハイポハイポのシューリンガン
スカイダイビングの高度の新記録に挑戦、というような記事を読んでいて、 "hypoxia" という単語が出てきた。 hypoなんとかっていう単語、よく見るけれど 今まで何となくしか把握してなかったのでちゃんと調べてみる。
まず接頭辞hypo-。今まで何となく「低い」とか「下の」だと思ってたんだけど、 分野によってニュアンスが若干違うようだ。
http://en.wiktionary.org/wiki/hypo-
(anatomy) Below; beneath; under.
(medicine) Deficient; less than normal.
(chemistry) A name for oxoacid and oxyanions with a low amount of oxygen.
「足りない」系
- hypoxia : 酸素(oxygen)が十分に行き渡らない。低酸素症。hypo+ox[y]+ia。ニュースでよく見る。
- hypoxemia : 血中 (-emia) の酸素分圧が足りない。低酸素血症。hypo+ox[y]+emia
- 「血」を表す接尾辞 -emia (e.g. anemia 貧血) は -hemia とも。接頭辞 hemo- と同源か。
- hypothermia : 温度が足りない。低体温症。hypo+therm+ia。ニュースでよく見る。
- hypophagia : 食が足りない。食欲不振。hypo+phagia
- -phagiaは食べることに関する接尾辞。dysphagia 嚥下障害。
- 但し拒食症はanorexia (an+orexia)。でも過食症はhyperphagia。
- hypothyroidism : 甲状腺(thyroid)機能低下症。
- hypoallergic : これは身体症状じゃないけど、食材の表示とかでよく見る。 アレルギーを起こしやすいものがあまり入ってないこと。
「下にある」系
- hypodermic : 皮下注射、またはそれに使う注射針。hypo+dermic。
- dermは皮膚の。皮膚科はdermatology。
- hypothalamus : 視床下部。thalamus(視床)の下。
- hypothesis : 仮説。これはthesis以前、みたいなニュアンスなのかな。
他
- hypocrisy, hypocrite : 偽善, 偽善者。これはちょっと語源がめんどい。
Tag: 英語
2012/03/17
直交世界の地図
ライブラリや言語要素は、なるべく独立した、互いに直交な機能を提供すべきだ、 という原理を私は信奉している。(1)学習すべき言語機能やAPIの数を抑えつつ、 (2)それらをシンプルに組み合わせることで「できること」を最大化する、 その最適解だからだ。
(単に(1)を最小化したいならS,Kコンビネータでもチューリングマシンでも いいんだけど、それだと(2)で組み合わせる方法が複雑になる。 必要な機能そのものを実現するAPIをその都度作っていると(2)の組み合わせは 最小化されるけれど(1)が爆発する。)
なんだけど、この直交する「軸」が増えてくると、 ほんの2要素の組み合わせであっても、発見が難しくなりすぎるかもしれない。
最近、Gaucheでコンマ区切りファイルを読んで処理するにはどうする、
という話題を見かけた。Gaucheリファレンスで"CSV"を検索したらすぐに
text.csvモジュールは見つかる (refj:text.csv)。でも
そこにある読み込みAPIはひとつ、
「CVSファイルの1レコードを読み込む手続きを作る」関数
make-csv-reader だけしかない。
これが例えばRubyのCSVクラスをだと、色々なAPIが提供されていて、 このページだけ見ればすぐに使えそうだ。
http://doc.ruby-lang.org/ja/1.9.3/class/CSV.html
# ファイルから一行ずつ
CSV.foreach("path/to/file.csv") do |row|
# use row here...
end
# ファイルから一度に
arr_of_arrs = CSV.read("path/to/file.csv")
# 文字列から一行ずつ
CSV.parse("CSV,data,String") do |row|
# use row here...
end
# 文字列から一度に
arr_of_arrs = CSV.parse("CSV,data,String")
Gaucheでは、make-csv-readerの戻り値を
他の手続きと組み合わせて使うことが想定されている。
(do-ecを使う場合は(use srfi-42)しておく)。
;; ファイルから一行ずつ
(call-with-input-file "path/to/file.csv"
(^p (port-for-each (^[row] #|use row here|#)
(cute (make-csv-reader #\,) p))))
;; あるいは
(call-with-input-file "path/to/file.csv"
(^p (do-ec (: row p (make-csv-reader #\,))
#|use row here|#)))
;; ファイルから一度に
(use util.file)
(file->list (make-csv-reader #\,) "path/to/file.csv")
;; 文字列から一行ずつ
(call-with-input-string "CSV,data,String"
(^p (port-for-each (^[row] #|use row here|#)
(cute (make-csv-reader #\,) p))))
;; あるいは
(call-with-input-string "CSV,data,String"
(^p (do-ec (: row p (make-csv-reader #\,))
#|use row here|#)))
;; 文字列から一度に
(call-with-input-string "CSV,data,String"
(cut port->list (make-csv-reader #\,) <>))
まあ、RubyのAPIよりやや冗長であることは否定しないけど、 「ポートから1レコード読み込む」という操作さえ提供しておけば、 後の組み合わせは共通だ。 「ファイルから読むAPI」「文字列から読むAPI」… などを個別に提供した場合、 今後パーズすべきフォーマットが増えていった場合に、 各フォーマットモジュール毎に統一した形でそれらを定義していかないとならない。 とはいえ、良く使う操作なら簡潔に書けるようにしておくっていうのも重要なんで、 バランスの問題ではある。
ただ、今回難しいなと思ったのは、
初心者が「CSVファイルを処理したいな」と思って検索してtext.csvのページに
たどりついても、さてそこからどうするか、次の一手が見えないだろうな、ってことだ。
各モジュールの独立性を高くしておいたことが、使い方を探す立場からは障害になる。
リファレンスマニュアルに具体例をたくさん書いておくというのは当面の解になるだろうけれど、 直交性の軸が増えると組み合わせの数が爆発するわけで、全ての可能性について 例をあげるという方針はスケールしない。
静的型言語だと、「この型の関数をはめ込めるパターンはどれ?」っていう具合に 検索をかけることができる。何らかのメタなアノテーションをAPIにつけられるように しといて、それを手がかりに探索できるようにするって手はあるかもしれない。
もう一つの問題は、要素群 X = {a, b, c,...} と要素群 Y = {j, k, l,...} から
要素を取ってきて組み合わせる、という使い方がポピュラーな場合に、
使う側は、たとえばbとjを組み合わせるなら(use b)と(use j)を
書かないとならないこと。具体例としては、ダイジェストのハッシュを計算して
ハッシュ値の16進文字列を得たい、というとき、ハッシュアルゴリズム
(e.g. (use rfc.md5) ) とダイジェスト汎用のユーティリティ (use util.digest) が必要になる。
こういう組み合わせが増えてくと、アプリケーションの冒頭にuseがずらずらと
並ぶことになって、これがどうも気になっている。ダイジェストアルゴリズムのモジュール
それぞれに16進文字列化のAPIをつければuseが減るんだけれど、
モジュール間の直交性がそのぶん減ることになる。なんかうまい方法はないかのう。
Tags: Programming, Gauche
2012/03/16
Y Combinatorの7年
Paul GrahamがY Combinatorを始めた頃について書いていた。
シード段階---企業がまだ、2人の若者と初期のアイディアに過ぎない頃---に 小額を投資して育てるファームってのは今やたくさんあって、 このコンセプトが有効であることは広く受け入れられている。 それだけに、2005年当時そのアイディアが どう感じられたかを思い出すのは難しくなりつつあるかも。
外側から、そして現在の地点から振り返って眺めれば、 Y Combinatorはスタートアップのあり方を変える、野心的な試みだったと評されるかもしれない。 でも開始当初は全くそんなことはなくて、もっとずっと気軽な感じだった。 第一回の募集は 「学生向けの夏のプログラム」だったんだよね。 世界征服の野望を慎重に練り上げるというよりは、単なる思いつきで始めたようにさえ見える。
(もっとも、この「思いつき」がPaulの頭の中で結晶してくるまでに、何年かの潜在的な 準備期間があったことは無視すべきではないだろうけど。『ハッカーと画家』はY Combinator以前に書かれたわけだし)。
注目すべきは、多分、YCのアイディア自体ではなくて、 そのアイディアを思いついた後のアクションなのだと思う。
3月11日にエンジェル投資ファームを始めよう、と決意して、2日で $200Kを用意。 1週間ほどで第一回のプログラムのアナウンス。 この身軽さと、決めたことに飛び込む覚悟の良さ。
身軽なだけならただの無鉄砲だけど、Y Combinatorの強さのひとつは、 「実行して、結果を見て、方針にすぐ反映する」というサイクルを高速に回していることだろう。 当初は学生の腕試し的なコンセプトだったのが、翌年には経験を踏まえて「学部は卒業しといた方がいい」ってことになってるし (『学生のためのベンチャー指南---A Student's Guide to Startups』)。その後もプログラムを毎回調整していて、ただ漫然と同じことを繰り返しているわけではない。
象徴的なのが最近発表された、アイディア無しでの応募も可とするという試み。 起業において「アイディアは(それ自体では)価値が無い、実行が全てだ」と語る人はたくさんいるけど、最初のアイディアさえ無くても良いよ、というのはかなり大胆だ。 とはいえ、この試みだって単なる思いつきではなく、 Y Combinatorのこれまで経験に裏打ちされてるわけで。
こうも言えるかも。Y Combinator自体の成長過程が、Y Combinatorが良いと考えるスタートアップの成長過程を反映している。メタサーキュラーですな。
Y Combinatorの成功を見てそのアイディアを コピーしようとしているところはたくさんあるけれど、 コピーすべきは目に見えるアイディアではなく、アイディアと実行を回すこの メタなエンジンなんじゃないかと思う。そして、超循環エンジンを実装したら、 具体的に出てくる運営方針というのはY Combinatorとは全然違ったものになるかもしれない。
おまけ: ボストンのかつてのYCオフィス (2006年)。YCがシリコンバレーに拠点を完全に移したので、 ここは既に引き払われている。
![[image]](http://blog.practical-scheme.net/images/yc1.png)
![[image]](http://blog.practical-scheme.net/images/yc2.png)
Tags: PaulGraham, YCombinator
2012/03/15
ピアノレッスン40回目
- Shostakovich: Prelude and Fugue Op87-7 (A major)
- プレリュードはup to speed (M=76)、フーガは二分音符=58 (楽譜指定は92)。 やっと暗譜したんだけど、頭の中で一つの声部に集中してると他の声部が出てこなくなって 何回か止まった。フーガは頭の使い方が違う感じがする。
- "This music, the better you get, the easier it sounds."
- Kapustin: Op40-2
- 家ではM=104までいったけど安定しない。レッスンではM=100で。 三度のパッセージはちょっとでも迷いがあると力が入ってすぐに弾けなくなるな。 ただ、M=96突破した時も思ったが、やはり律速は指や手の運動機能ではなく 頭の方にあると感じられる。
ショスタコビッチのできあがりがそろそろ視野に入ってきたので、 「次どうする?」という相談。いくつか楽譜をsheetmusicplus.comで注文 してるんだけど、まだ届いてない。順序としては今度はロマン派かな、 ということでブラームスに手を出してみるつもり。
(ショスタコビッチの前奏曲とフーガもまだやりたいのがあるんで、 他の曲をいくつかやった後戻るつもり)
Tag: Piano
2012/03/14
fold, fold-left, fold-right
foldとfold-rightが左/右結合ってのはその通りなんだけれど、
畳み込まれる演算の引数の順序に注意が必要。
(fold op 'z '(a b c d)) (fold-right op 'z '(a b c d))
op op
/ \ / \
d op a op
/ \ / \
c op b op
/ \ / \
b op c op
/ \ / \
a z d z
左結合の方が関数型言語での主流の定義とはちょっと違う。
Haskellのfoldlに対応するのはR6RSで定義されているfold-leftの方。
(fold-left op 'z '(a b c d)) (fold-right op 'z '(a b c d))
op op
/ \ / \
op d a op
/ \ / \
op c b op
/ \ / \
op b c op
/ \ / \
z a d z
op が可換な演算ならfoldもfold-leftも変わらないんだけど。
図示するとfold-left/fold-rightの方が綺麗に対称になってる。
ただ、実用的な場面ではfoldの方が使いでがある、気がする。多分、
「頭からリストの要素を見つつ、結果をconsしてゆく」っていうSchemeで
よくあるループのパターンがfoldで実現されてるからじゃないかな。
とはいえ他の言語のアルゴリズムを持ってくる時に混乱が生じがちなので、
さっきGaucheにもfold-leftを足しといた。
Tags: Programming, Scheme
Comments (2)