ToDo:
気がついたら終わっていた。 topcoder とか codejam 系だったのかな。 じゃあまあいいんだけど。
飯をたくさん喰うという努力をしたら 速攻で気持ち悪くなって元々体調悪いのとコンボでキツくなった。 なんとかならんかという貧弱さ。
dc は手で書くのがかったるいので 適当な言語から生成したいと思う。 bc がそれであるのは知ってるんだけど、 そうじゃなくて短い dc コードを出力させたいのだよね当然
なるべくレジスタ使わないで stack を… とかいう話はいくらでも研究とかありそうだが
(19:05)
のでまぁその人は64問全部解いてるし 60問縛りとか意味わからんことやめて残りも解くことに。 適当に codegolf.com のコードの流用とかしつつ romancal 解いたので 1位取り戻した。 久々に見るとローマ数字とか死んでいいな。 だいたいゴルフ的には 8 は IIX であるべきだろうに。
残り3問だけど、
など、3つとも回避したい雰囲気なのであるがー
まぁ spiral はあきらかに簡単そうではあるよね…
(00:58)
http://www.spoj.pl/SHORTEN/ranks/
になった。 60問しか解いてないまんまなので伸びしろもそれなりにあるだろうっていうか そこらじゅう伸びしろだらけだろうと思う。
どうでもいいけどこの動画をずっと聞いている。 なんでこいうの好きなのか。
http://www.nicovideo.jp/watch/sm12628181
(17:01)
狂ったルールのおかげでたのしい。 ここまで来るとはなぁ。
http://www.spoj.pl/SHORTEN/ranks/SIZECON/
あと 2B は今の方針だと全然ダメ。 どうすればいいかなー
解いた問題数 60 のまんまでトップになりたいとか思いはじめてきた。
(11:39)
http://www.typemiss.net/2011/01/spoj-shorten.html
で書かれてる通りテストケースかなり適当なんだよなぁ。
http://twitter.com/kinaba/status/23392088473214977
まず kinaba さんが書いておられる通り出力フォーマットが適当ってのがあって、 それはまぁたぶん scanf で読んでるっぽい感じの問題が多くて、 そっちはまぁ
https://www.spoj.pl/SHORTEN/embed/rules/
あたりにも書いてあるからまぁいいとして。
問題はテストケース見せてないからなんとかなってるだけーって程度に テストケースが十分に無いやつがあるってことだよな。 例えば SUDCHECK なんてテストケースの数の bit 数があれば 解答埋め込めちゃうから、 こんなもんすごい数のテストケースが無いと ルール無用なゴルフとしては全く成立してないのだよな。
https://www.spoj.pl/SHORTEN/problems/SUDCHECK/
そんなこんなでまぁ色々やる気は起きない要因はあるんだけど、 なんか BF 使う問題とかあったりとかはちょっと面白いかとおもう。
てかこのへんの制約は ICPC のためにほげほげな SPOJ だから、って理由がほとんどだよなぁ。 あくまでゴルフ場ではないっつーか。
あと与えられてる sample inputs が異様に簡単なものばかり、ってのも ICPC 的な感じなんだろうなぁ。 問題の spec から難しいテストケースを考える、 ってのは重要な能力ではあるものの、 なんかどうもプログラムコンテストとしては余計なものに感じちゃったりもする。
まあなんだかんだ言いつつ3位。
一番面白かった問題(というか解いてないが)は INTER で ruby だと gets するだけで TLE 。 https://www.spoj.pl/SHORTEN/problems/INTER/
(08:20)
http://d.hatena.ne.jp/kawango/20110107
ニコニコではこのへんが問題になるのなーという感じもあるけど、 本当にそうなんか? グーグルだとなんか色々調べたけど、 ある程度高速な回線だと結局クライアントのオーバヘッドがデカいぞ、 って話で HTML を頑張って色々やったらユーザの幸せがだいぶ増えたとかいう話があって (たしかこの本…だっけ http://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309)、 ニコニコも体感だと動画とか以前に、最初にページ出るまでが結構長いんだけどな。
(10:09)
いくらなんでも gets だけでタイムアウトしてるのはおかしいが、 測ってみると ruby1.9 の gets はマジで遅い。 これは M17N の影響だったりするんだろうか。
> time sh -c "ruby -e 'puts %q(c)*10000000' | ruby -e 'gets'" sh -c "ruby -e 'puts %q(c)*10000000' | ruby -e 'gets'" 0.19s user 0.17s system 91% cpu 0.396 total > time sh -c "ruby -e 'puts %q(c)*10000000' | ruby1.9 -e 'gets'" sh -c "ruby -e 'puts %q(c)*10000000' | ruby1.9 -e 'gets'" 1.32s user 0.19s system 94% cpu 1.591 total > time sh -c "ruby -e 'puts %q(c)*10000000' | perl -e '<>'" sh -c "ruby -e 'puts %q(c)*10000000' | perl -e '<>'" 0.21s user 0.12s system 93% cpu 0.360 total
(10:46)
なんか IRC で話してていくつか
(05:25)
rejudge よりは rand seed 全部殺すのが良いんじゃないかと言われた。 そんなの無理だと思ってたんだけど、結構できそうな気もしてきた
最後の3つは色々互いに絡んでる恐れがあるかな。
話としては、
あとは他に乱数源ってあったかなあ… 普通に考えると /dev/urandom とか time 系だけだと思うけど…
(11:09)
http://www.atdot.net/~ko1/diary/201101.html#d4
まぁこいうのはどこでも時々起きる系なのかなあよく知らんけど
Ruby については ruby-dev は「こわい」という話を ささださんにしたらこわくないよと言われた気がする。 当時もうまく説明できなかったけど、今もよくわからない。 ささださんの書いてる fundamental な人が多いと感じがするというのは、 割とその理由の一つかもしれないけどわからない。
ドキュメントは新しい熱心な人が聞きながら作る、ってのは まぁ一般的によくある話だとなんじゃないかなぁ。 そしてそれでいいんじゃないかなぁと思う。 よくわかってる人が書いたドキュメントって往々にして 新しい人にとって全然便利じゃなかったりするよね…
(23:49)
文字通り一日中ゴルフしてた…
http://www.spoj.pl/SHORTEN/ranks/
とりあえず7位まで。問題多すぎですがな… まぁ codegolf よりは軽い問題が多いのはありがたいか。
トップの人は普通の問題に強烈に強い印象で、 2位の人は bash がおかしいことになってる感じぽい。
しかしなんか bash って使えるコマンド変わってる疑惑があるのがやる気を削がれるが
(01:35)
http://blog.goo.ne.jp/no_orz_no_life/e/e7110098e80d89e28082065d32e9dd6b
の fact とか sum を見てて、 あらなんで3つ式あるのかなーと一瞬思ったんだけど、 まあたぶん末尾再帰の最適化かけたいという話だと思う。
で、そういえば GCC はどのくらい無茶なものを 末尾再帰にしてくれるのかなーとか思って色々やってみたら、 どうもすごく単純な足し算掛け算くらいしかできないぽかった。
まぁそんなもんかーと GCC を見ると、
if (act->add && !a_acc)
a_acc = create_tailcall_accumulator ("add_acc", first,
integer_zero_node);
if (act->mult && !m_acc)
m_acc = create_tailcall_accumulator ("mult_acc", first,
integer_one_node);
とかあって、やはり足し算と掛け算だけ特殊処理されてるのかな、 って感じだった。
関数型言語系だと、末尾が cons だった場合なんかにも、 似たような処理をしてやれば ずいぶんと色々とラクになるんじゃないかなぁとか思った。
あと、足し算掛け算以外を色々考えてる間に書いた、
def factdiv(n)
if n==1
1.0
else
n/factdiv(n-1)
end
end
というような関数は、 つまり (2*4*8*...)/(1*3*5*...) という感じの値を返すわけだけど、 この値は 1.25 sqrt(N) くらいの数字になるみたいだった。 正確には (1*3*5*7*...)/(2*4*6*...) になってる時は 0.8 sqrt(N) くらいになってるので、この二つを繰り返すというか。
さてこれってなんか今まで見たことあるっけ… どうも見たことない気がするんだけど、 なんか有名な法則とかがありそうではある。
(23:39)
年越す時に書いてたコードは spoj のゴルフだと思う。 たぶん kamil 。 spoj のゴルフはなんかよくわからんくらい短いものが結構あって、 なんか答え埋め込みとかになってるやつもあるのかなぁ。
年明けてからは BF_PRIME で、正月早々 Brainfuck ってのもどうなんですかね… しかもどうも勝てる気配があまりなくてですね…
kinaba さんの書いておられた、 なんかに特化した言語作るってのはいいかもなぁと思ったので、 Brainfuck の短いコードを出力するプログラムに特化した言語というのはどうか…
去年は今一つ、色んなことに慣れすぎてて特に何も無かったなぁ…という感じがした。 そいうことを思いながらはてなとか見てみた。
とかあったんですが、このへんは知ってることまとめたりとかそういうのばっかで、 今一つ新鮮なことではなくて。
というわけで自分的に一番重要だったことは wake は今年作ったんだなぁということな気がする。
あとまぁ後半は Starcraft2 やってたなぁとしか言えないんじゃないかね。
(23:57)
電車の中で暇だったのでだいぶ前に書いてた ld-mach-o を見てた。 クラッシュしてるところはどうも strcmp の中らしい。
gdb の reverse-stepi とかあのへんはじめて使ったけど、 さっさとクラッシュしてるようなケースだと便利だなぁ… と気付いた。 実益ないとバカにしてた record だけど、 まぁなんか使いかたあるかもなぁとか思いはじめてきた。
なかなかクラッシュしてくれないプログラムを考えると、 「クラッシュするちょっと前」を探してそこから record してくれると嬉しい。 しかしこれはどう考えても簡単じゃない。
たぶんタイマーみたいなのを仕込んで、 時々止めてみて rip を記録して、 次回は最後に止まったところで止めて record を仕込んで…とか考える。 ただその止まるようなところはどうせ何度も通るようなパスなんですねー。
はてさて
あと raw_write が TCC で動かないのがムカついたので インラインアセンブラをいじりはじめる。 raw_write は動いた。 r8 から先が全く対応されてないのでなんとかしたい、気がする。
(00:01)
ファイル保存可能問題がふたたび。
どうも /var/lib/php5 と /var/cache/common-lisp-controller が writable だったようだ。
これらはなんか writable であるべきってことで writable ぽいんだけど、 とりあえず hello world くらいなら php も clisp も 755 で動いてやがるので、とりあえずこれでいいかと放置。
問題あればおしえてください
(11:58)
| 前 | 2025年 1月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ kosaki [getsの問題、うちでは再現しませんねぇ。ruby19がtrunk+linuxなのが原因かもしれませんが。]