https://twitter.com/kinaba のログ (twilog の方が便利です。)
| @mametter 日記にも書いたようにゲート推測は良いと思うよー。他の二つがいただけない。 | |
| 車の方は http://sequitur.info/ みたいな文脈自由文法推論アルゴリズムでどうにか解けんかみたいなことを @mayahjp と話していたけど二人して名前を思い出せずググれなかったので断念したりしてた | |
| @mametter 超絶難易度でないというのは、解けたチーム数を見る限り同意しかねるなあ。スコア取れたチームの率2007年を下回って最低を記録しているような…。難易度以上に、「プログラミングコンテストと聞いてプログラムしに飛んできました！」って層を一目で諦めさせちゃうのが勿体ない | |
| @mametter 蓄積効果は確かにそうだ、それも思った。 | |
| @mametter えー2007のVMを作れないのはプログラミングの腕の問題なのでそこでの門前払いは差し支えないと思うのだけど。その次に来る、別のページ番号を入れたら他の情報が手に入ると推理して云々とかで情報揃えるフェーズは今年のパズル同様に嫌いです。 | |
| @tsukuno さんは普通に問題文書いても一般人からするときっとguessゲーになる | |
| ICFPc、参加した中で好きな順にならべると 2006＞2010＞2007＞2004＞2009＞2005＞2008＞2003 こうかなあ。なんだかんだいいながらパズル系が上位に来ているのは否めないのですが！2006,2007,2004は関数型っぽい！と思った度の高さが理由で(続) | |
| (続) 2010は http://twitter.com/nya3jp/status/16699423555 こういうのが重要になるのは凄い健全と思うのでという理由が実は一番大きいかもしれない。車操作系は、操作の自由度が高いものほど好きだという理由で2009。なんか2008や2003の車は思うように動かなすぎて泣きそうだった | |
| @mametter そうそう。ただこれは「マネジメントしなきゃいけない大量のデータ」と対になってしまうような気がするので、どうしてもサーバ重いというマイナスがセットで付いてきちゃいそうで、なかなか上手く問題作るのは難しいですよね。 | |
| @mametter 2004は僕には難しすぎて途中で挫折したのであまり深く理解してないのですけど、蟻言語と蟻コンパイラ必須な感じにまで話が持ち上がってくれる問題だったので、これは良いなあと思いました。 | |
| 「ICFPコンテスト好き嫌い」をトゥギャりました。 http://togetter.com/li/31137 | |
| はじめてtogetter使ってみたけどこれ流れを全部追うのしんどいなー。抜けまくりな気がする。いつもC++ TLをまとめてらっしゃる @zakkas783 の凄さを今思い知りました。 | |
| 不自然言語処理コンテスト http://www.baidu.jp/unlp/ になんかつなげるとか RT @kinaba その全自動化をやるコンテry (via @tsukuno) http://twitter.com/tsukuno/statuses/16786425373 | |
| @mametter 僕のレスが遅くてどれに反応返してるのかがわかりにくいのがよくわかるまとめです！ | |
| そういえば僕はいつも一人で出ようとしているのに何故か最終的に @tsukuno さんに巻き込まれている | |
| TopCoderのAlgorithm部門やICPCっぽい方向の問題をややパズルチックにした問題（も含む）コンテストだと、この前やったIPSC http://ipsc.ksp.sk/ は面白かった。 | |
| .@nishio さんの http://d.hatena.ne.jp/nishiohirokazu/20100622/1277208908 手元で再現しないなあ。10万:1.05sec 20:2.28 30:5.14 40:8.22 50:12.00 100:20.85 (ghc 6.10.1 --make -O3, c2duo1.4G, 3GB) | |
| いやしかしsubquadraticなのはなんでだ | |
| Integer加算の分を考えると話が複雑になるので、とりあえず0,0から始めてみる http://codepad.org/FgRsOFi7 と、at0 と at1 が同じくらい（当たり前）で、at2 が圧倒的に速い。速いのは当然なんだけどオーダが違うように見えるのは、えーと… | |
| ひい zipWith (+) (tail fib) fib にしたらGHCの吐いたバイナリが落ちた internal error: schedule: invalid what_next field | |
| とりあえず最新版にしてから考えよう | |
| +の引数の計算ではなく、+の計算自体を正格評価しないと変わらないので、遅延をやめるならば zipWith' f (x:xs) (y:ys) = ((:) $! (f x y)) (zipWith' f .. http://togetter.com/li/31078 | |
| ghc -C の出力はいざ読もうとしてみると意外と読めるな。昔みたときは完全に暗号のような印象だったのに | |
| @hassyX 残念ながら絶版ですが http://www.shuwasystem.co.jp/products/7980html/0958.html 『フルスクラッチによるグラフィックスプログラミング入門』 はいかがでしょうか。探せばまだ見つかる…かもしれません | |
| いつの間にか "Kazuhiro Inaba" でグーグルトップを奪えていた http://www.google.com/search?hl=en&q=Kazuhiro+Inaba いぇい。"kmonos" は抜かれるのも時間の問題だろうなー。 | |
| @shnsk ありがとうございます。これで海外の人に会ったときに「ググると一番にヒゲのおっさんが出てくるからキミもヒゲを生やせ」とか言われずに済みますw | |
| @kikx あんまり覚えてないですがサンプルは結構mayahさんのでも難しかった記憶があります | |
| http://homepage1.nifty.com/herumi/diary/1006.html#23 ううむ、複雑に考えすぎではないでしょうか…。fib=1:1:... は単にリストを作って変数fibに持っている式なので、素直に動かすと全リストが保持されます。たまたま１回しか使わないならば残す必要がないので最適化で消えるだけで。 | |
| 最適化でじゃなくてこの場合はGCでかな。どっちだろう。!!とzipWithが融合されて消えているのか、GCで適宜回収されているのかどっちか。 | |
| 遅延評価だと（正格評価のつもりでいると予想しないところでメモリを食う、ので、メモリを食うとGCの影響やメモリ階層の影響がフクザツなので）実行時間が読みづらい、というのはあると思う。けど、実行される演算の回数は、必要な演算は結局最後には全部呼ばれるので、深く考えず普通に数えればok | |
| @yzn8 昨年から、笹田さんにお誘いいただいて講師ということにさせてもらってます。いやほんと、どっちかというと教える側よりも、Linux組あたりにフルタイムで生徒として教わりに行きたいんですが… |