ToDo:
LLVM に投げてた趣味パッチが submit されたぽい。
http://llvm.org/viewvc/llvm-project/?view=rev&revision=160899
こっち見るとわかるのはこれのせいで ICFPC に 15 分ほど出遅れたということですね…
http://llvm.org/bugs/show_bug.cgi?id=13351
内容はしょうもなくて、 GCC だと入ってるけど LLVM は入れない dwarf の情報をひとつ入れただけ。 binutils がそれ使って読まなくていいとこの読み飛ばしをやってるんで、できたバイナリを addr2line するのが10倍くらいはやくなったりする。
テスト結果変わるから修正したりテスト増やしたりしてて気付いたんだけど、 lit とかいうテストツール使ってるんだなと。ぱっと見 dejagnu みたいなもんなんだけど、こういうテストツールみたいなのはプロジェクトごとに再生産した方がいいのかもね…とか。
(12:43)
leonid 先生と会う機会があったので4時間とか喋ってた。印象はなんかこの人なんでもよく覚えてるな…っていう。色々興味深い話を聞いた。覚えてるので面白かったのは、
http://golf.shinh.org/p.rb?Verhoeff+Algorithm
の問題。これ python が異様に短いんだけど、これにはタネがあるっていう話。これ出題した SeeNoEvil さんは短いコードを submit してあったんだけど、他の誰もタネに気付かないからヒント、ってことで SeeEvilRedBalloon って名前で投稿したと、で red balloon は base128 のデコーダ書けって話で、こっちの問題のテストケースを base128 で溶かすと python コードが出てくるからそれを exec するだけ…て話らしい。おもろい。
で、なんか coding session みたいなのすると楽しいんじゃないかってことだったので、いいねってことで、今度の月曜のたぶん19時くらいに問題投稿して1,2時間程度の勝負をしようみたいな話になった。日本時間だと火曜11時? 参加しにくそうですが暇な人は競ってくれればな…と思います。
あと言ってたのは、ペアプロでやるとかも面白そうだね、とか。チーム戦とか楽しそうではある…
(14:13)
4人席で2人で昼飯喰ってて、外人が寄ってきて、なんか聞く。文脈的に、「この椅子持っていっていい? 」か「この椅子誰か使ってるわけじゃないよね?」とかそんな質問である。実際僕の漠然としたリスニング能力も特にこの仮説を否定しない。
でこのへんで僕は投機的に yes と言ってしまう。質問がどっちだとしても、日本語だと、「うん」が正しい答えだから。で、言ってしまってから、ああ否定質問に、日本語で言う「うん」と言うには No という必要がある、っていう超基本的なことが頭によぎって、しまった No と言いなおさなきゃ、でもそれ以前にそもそも大本の質問は後者なんだっけ…とか、そのあたりでこう脳は全力で考えてるもののなにか言わなけりゃ、ということでタイムアウトした時の処理が走ることになる。タイムアウトの処理は比較的単純で、前回発話した単語からハッシュをひいて、その後にマルコフ連鎖的な意味で一番頻度が高い単語が出てくる。 "Yes" と既に言ってしまってるから、そのあとの単語は人工無能的には当然 please である。
この yes please というのは論外だってのは最初からわかってるし、そもそも sure とか go ahead とか言っときゃ無難だったのはすぐわかるんだけど、しかしこう既に愚かな発言をした後であって、はてどうしたもんかと思ってる間に相手は椅子を持ち去ってくれて、特に問題は起きない。いやあ相手が適当にこっちの意図を組んでくれる人で良かったなーと思うんだけど、 google ではたらいてる人とかはこういう意図を組んでくれる確率が非常に高くて、まあなんだかんだで頭いい人達だってことなのかなぁとかよく思う。あんまそれに頼って意思疎通するのよくないよね…
(15:19)
あと、なんかこう、 I always uses とかよく言ってしまう、って話をした。 uses は当然 use が正解。こういうミスをする理由もまたマルコフ連鎖で、僕の中では I or you なら動詞は use で、「それ以外」なら uses 、ってのが結びつけられてる。この時なんでまちがうかっていうと、 always がはさまってて、それは「それ以外」だから uses だろう、みたいな、ここまではほとんど考えてないレベルでの脳の反応だと思う。
でまあ、これはべつにひとつ前の話と違って、まぁぶっちゃけ間違っても問題なく通じるから、単純にほっとくと良い。言いなおしたりするとかえって混乱を招くから、言いなおすべきじゃない。そのへんはわかってるんだけど、しかし頭の中では「あー今 s/uses/use/ だなー」とか考えちゃう。それはまぁ日本語とかだとそんな問題なくて、多少ヘンな喋りかたしてしまって(こいうのは敬語がからむと結構あるころで、敬語で言うべき動詞を丁寧語で言っちゃった時とかに一瞬考えると思う)もまぁそこまで会話の流れに影響を及ぼさないんだけど、英語でこの手のミスをすると、「あーしくった!」「今のusesはuseと言うべきだった」「あーalwaysがはさまったせいだな!」とか、そいう思考が脳をかけめぐってしまう。でも、英語喋ってる時とかは少ない脳のCPUリソースが全部英会話に行ってるわけで、かつ全ての思考を英語に使わないとキツいわけで、比較的重要でないs/uses/use/問題とかにCPU時間を使ってる場合ではない。でもなんかあれこれ考えてしまって…みたいな感じで、よく詰む。
(15:33)
アンタのコードは大きいマップで大丈夫なの? と聞かれた。いい質問だなぁと思ったので、 tanakh さんとこのチームのリポジトリにランダム生成されたマップがあったなーと思い出したので、適当にやってみた。
https://github.com/tanakh/ICFP2012
結果としては、 128 と 256 くらいはまー一応 positive なスコア返す結果を出してるみたいだ。 1024 は10秒くらいで切り上げるとなんか 1byte とかの結果出してて、つまりとなりの lambda 取っただけ、って感じですかね…もうちょい待つとまぁそれなりに長い答えが出たり出なかったり。まぁでも正直動いてることに感心、ってだけの話ですね…
一応画面の更新は Growth のタイミング以外では全体をなめないようにしてあるんで、 befunge とはいえ、まぁまぁな速度で動いてるはずなんで、まーそんなもんかなー的な感じ…
(15:43)
http://www.cs.dartmouth.edu/~doug/mdmspe.pdf
via http://research.swtch.com/qsort
「quicksort の最悪計算量は O(n^2) ですよ、でも pivot のとりかたとかでだいたい大丈夫にすることはできますよ」、ってのはよく言われる話だけど、実際 quicksort が n^2 になるようなデータを作る方法を考えてみた、っていう話。
作りかたがちょっと面白くて、 qsort を実際に呼んで、 callback で呼ばれる比較関数で小さい数字から少しずつデータを確定させていく、みたいな。
このコード、 mac とか linux で実行してみると n^2 にならない。 russ cox によると glibc の qsort は実際は merge sort らしいからそういうもんらしい。 mac もそういう感じなのかな。 N が小さい時はわりと n^2 ぽい挙動してるけど…
ぱっとコード見た感じ、 2*(log(N)-1) 回越えて再帰する時は heapsort する、みたいなコードに見えるかな。まーなんとなくわからんでもないし、あとまぁそれならそういう挙動するかな的な。
自分で適当に qsort 書いてみて antiqsort に渡してみたら、モロに O(n^2) になった。おもしろい。 qsort は C だとっていうか余計なメモリ使わない実装は結構むずかしいと思ってて、昔書いた時はすっと書けなかった気がするけど、今回はそんなに苦労しなかった。全然テストしてないからあってるかは知らんけど。
void myqsort(void* base, size_t nel, size_t width,
int (*compar)(const void*, const void*)) {
char* pivot = (char*)base;
char* b = pivot + width;
char* e = (char*)base + nel * width;
char* buf = (char*)malloc(width);
size_t lc = 0;
while (b < e) {
int r = compar(pivot, b);
if (r >= 0) {
b += width;
lc++;
} else {
e -= width;
memcpy(buf, b, width);
memcpy(b, e, width);
memcpy(e, buf, width);
}
}
if (lc) {
memcpy(buf, b - width, width);
memcpy(b - width, pivot, width);
memcpy(pivot, buf, width);
myqsort(pivot, lc, width, compar);
}
free(buf);
if (nel - 1 - lc)
myqsort(b, nel - 1 - lc, width, compar);
}
(16:59)
こういうマップを妄想してた。
###L### # \\\ # # # # # # # #* # # * * # # * # # # # # #* # # # # # # *# # * * # # * # # # # R # #######
僕の AI に解かせてみたところ、なるほどこのロボット頭で岩止めれるのか…と気付いた。
(01:56)
2時に寝て8時に起きてしんどすぎると二度寝して、11時くらいと12時くらいと1時くらいと2時くらいでそれを繰り返して、明日からアメリカだから休もう…とメール書いた。で、また3時くらいでそれをやって、その時飯を喰って、あと2回そういう繰り返しをして今に至るがまだ体だるい…
とりあえずそろそろ準備しないとな…
(19:41)
http://herpolhode.com/rob/utah2000.pdf
読んだ。まーそうなんだろなっていう。よくわかってないけど CS とか半分くらいはそろそろ大学でやることじゃないんじゃないかな…てのは割とずっと思ってることだけど。
計算量とか数学系は続けりゃいいと思うし、科学技術計算のための大型計算機とかもやりゃいいと思う。ただシステムプログラミングとかは、もう企業にやらせりゃいいんじゃないかな…ていう感はある。12年前の rob pike の苦言を見て、そんな感じなんだろうなあと今思うてことは、たぶんあんま良くなってないんだろうな…
(21:43)
kinaba さんの動画ぼんやり見ててソルバというかシミュレータのバグに気付いた。
トランポリンの入口入った時に同じ出口に向かうやつ全部消えるってやつ、消さなくても次入ったら消える感じでいいかなーと思ってたけど、上に乗ってた石は動きだすべきなんだね…くそう完全に正しいの作れたかなーと思ってたのにがっかりだ。
これくらいはまぁ大変だけど実装できた気がするな。つっても1時間くらいはかかるだろうから、きわどいところだなー。
C++ より次元が多くてすばらしく見える Befunge 欠点は変更がしづらいことで、基本一度書いたコードの位置を移動させようとすると、多大な苦労を強いられることになる。特にメモリレイアウトとか変えようとすると死ぬので、最初にだいたいこういう感じで書こう…と決めた通りになるべく進めたい。
読みにくいのも問題といえば問題で、あーあそこバグってるなーと思っても、実際バグってるコードを探すのが結構大変。たった100行程度のコードなのに! 普通はそういうのをふせぐためにコメントを書いたりすると良いわけだけど、コメントがこれまた書きづらい。というのは、コメントに副作用があるのが問題で、ここは絶対に実行されてない、と確信を持つのに時間がかかるし、将来的にここを通したくなることは無い、って言える場所が少ない。例えば、
> このへんからメインループがはじまる
>
| ゴール判定のためにラムダの残り数を数えるコードがこのへんにある
goal->@
^ 1ターンが終わると端を通って戻る
みたいなコードがあって、上の例だと親切のつもりで書いた goal ってコメントが、 g は Befunge では実行できる命令なので、特にエラーも出ず、スタックの長さが突然変わることになる。この例みたいな重要なコードパスならまーすぐ気付くだろうけど、あんまり通らないとことか、あるいは今トランポリンを集中工事してるんだ、って時に洪水のとこがバグったりすると、すごい遅れて気付くことになる。というわけで今集中してるとこ以外はいじらないのが得策で、コメントもほとんど書けない感じだった。一応、未実装のとこは付近に空間ができがちなんで、 @ で潰して近くに文字列置いたりはしてたけど。
うーむ残念だ。他にもバグあったりするかなぁ…
(00:43)
README が文章も typo も無茶苦茶ですがな。英語がうんぬん以前に論理的につながって無い系。
こう疲れてるんで、 README は後から提出できる感じにしてほしいよね…
(01:21)
3日間聞いてたのは、ウテナ→ミク→ぷよm@s という感じだった。基本的になんかやかましいのが鳴ってると集中できるんだけど、ウテナとかミクずっとはさすがにうざい。ていうかミクはわりとすぐにつらくなってやめた。
ぷよm@s は色んな音が流れつつ、たまにやかましいのが流れるのが僕的には作業向けなんだけど、丈が短いからすぐループしはじめる。別な part に移動したらいいんだけど、今回は細心の注意が必要すぎる作業をしてたので、結果としてなんかずっと同じ曲聞いてた気がする…
それで思い出したんだけど、 part27 のあずささんの連鎖がいつ見てもすごいと思い出した。コレの11手目。
http://ips.karou.jp/simu/pv.html?_0uk8iiSkCukaiucgkwkIcgcKMKW-S1
via http://unknown72.seesaa.net/article/235037702.html
フツーに考えるとこういう12手発火5連になる気がする。作中で指摘されてたのは4+5の4ダブで、初代だとそっちの方がいいんだろうけど。
http://ips.karou.jp/simu/pe.html?_0uk8iiSkCukaiucgkwkIcIcaMKW-S1
(01:50)
いつもメモり忘れるけど、このモードを使うと Befunge のコードが書きやすくなる。
しかし自分ではっつけた結果をよく見ると、 contest2.map で C++ コードが befunge のコードに負けてやがってうける。
(21:56)
最近思うことは飽和連鎖量が足りないなっていう。で、ぐぐってたら最初に出てきたやつ
http://www.geocities.co.jp/Playtown-Domino/6390/Bulletin/lecture/lecture6.html
これが、モロにGTR系なのに
C B CC BAA BAC
とかいうキツい形が最初に思いついてダメだなぁとか思った。ちょっとゆっくり一手一手考えるみたいなことした方がいいのかな…
あと初手で
BA BBA AAC
とかできた後に AB AC AD どれが来てもわりと悩むことが多い気がするなぁと思った。ネクスト考えないと、どの場合も A を5個消ししちゃうのが良いのかな… AC AD は2列目に立てるのもいいと思うんだけど。
(01:02)
A BC CCA BACD BBACDC AACCDC
の ABAB が
A AB BCB CCA BACD BBACDC AACCDC
とかになりがち。
BAB CAB CCA BACD BBACDC AACCDC
なら全然よいということを考えると、左端のフタが一つってのがイマイチ系なのかな…
(01:07)
i@u6 0:46 [master]
> cat non_static_data_init.cc
struct S {
int i = 42;
};
i@u6 0:46 [master]
> g++ -std=c++0x non_static_data_init.cc
non_static_data_init.cc:2:11: 残念ですが未実装です: non-static data member initializers
non_static_data_init.cc:2:11: エラー: ISO C++ forbids in-class initialization of non-const static member ‘i’
zsh: exit 1 g++ -std=c++0x non_static_data_init.cc
そ、そうですか…
(00:47)
http://blog.64p.org/entry/2012/07/11/224008
via https://plus.google.com/102550604876259086885/posts/AnEoGQexUcG
scons なんて始まってもいねえよ! ってのが僕の感覚だなあ、たいしてしらないけど、必要じゃない機能ばっか充実しているという mukai さんのイメージに賛成する感じ。
scons に関していつも言ってる悪口に、ファイルが本当に変更された時にだけ依存関係をビルドしなおしてくれるという便利な機能がある。
これはどういうことかというと、 hello.c から hello.o と hello を作ったあと、 hello.c を touch してもビルドしなおしてくれないと。 stdio.h とか書きかえた時とか、そういう特殊なことしてるからわざわざ touch してるわけで、なんか余計なお世話としか言えない。で、しょうがないなと hello.c の末尾に空行を一行足したりすると、 hello.o はリビルドされるけど hello はされない。何故なら hello.o のチェックサムは変わってないから。
そしてその余計なお節介にしか思えない機能が自慢気に書いてあるあたり、なんかすくなくとも僕の感覚とはずれてるなあ…としか思えない。
http://www.scons.org/doc/0.98.5/HTML/scons-user/c779.html
で、まーそういう余計なお節介があると知ると、あの遅さがそういう余計なお節介のせいではないか…とか思われて、どうしたもんかと思ってしまう。
ただ、一応今ぐぐってみると、色々速くする方法はあるみたいだ…ただ make 系ツールのデフォルトの挙動を遅いものにするセンスからして、このへん頑張っても make 程度にも速くならないんじゃないかな…とか思ってしまうよね…
http://www.scons.org/wiki/GoFastButton
あといつも言ってることだけど、ビルドシステムってのは、こうなんか、人々に再生産させたくなるようなオーラがただよってるらしく、なんか許しがたい数既にあるので、 make にムカついて僕の考えた無敵のビルドシステムを作ろうとしてる人はコレを見て考えなおしてほしい…
http://en.wikipedia.org/wiki/List_of_build_automation_software
mukai さんも書いてる通り、 automake/cmake/gyp あたりは一つ上のレイヤにいるので、そのへんはまぁ OK 。 autoconf のレイヤは特に代替があまり作られてない気がするけど、まぁ Unix 乱立がおさまりすぎて、ああいうのの時代は終わりつつあるのかもな…
ところで autotools はひとくくりにして、嫌ってる人が多い気がするけど、僕的には autoconf は必要で automake は死んでもいい派。 autoconf 無しだと、わりと色々詰んでると思うんだけどな… cmake は autoconf 的なことを少しだけしてくれた気がしたけど、どうだっけ…
libtool は実際問題正しくライブラリ用の make 書ける気がしないから、本質的じゃないけどあれも必要かな…とか言ってると automake 無しで libtool 使うの大変とかで必要になってきて、こまるわけだ…一度 automake 抜きで autoconf/libtoolize 使うとか練習してみるのも良いかもしれない…
(00:57)
sucks シリーズ、 JS はあまりよく知らないのにすごいのがいっぱいあるから書いてなかったけど、ちょっと書いてみた。
http://shinh.skr.jp/h/?JSSucks
(01:23)
| 前 | 2025年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ mtve [:)]