ToDo:
250 は 4 と 7 の組み合わせ…とか考えて 250 にしてはそれじゃ難しいかと思って、 ああ下のケタ見るだけでたぶん OK かーと気付く。 n % 10 で適当に場合わけして、 うーんこれでいいんだろうかなんか実はもっと短い組み合わせでいけるケースがあったり… とか疑ったり、こういうの僕ミスるの得意だよなぁ…とか思ったりして、 ruby で適当に組み合わせ作ってみたところ、 別にどうも無いっぽいなぁでもなんかミスってたらイヤだなぁ…とびびりつつ submit
550 は 500 より多いのかあ難しそうだなぁと思いつつ、 long long が overflow するから割り算を手書きして… とかやって平均値を求めてみてから、 これ実は naive に書いてある通りのループ回して後調整したらいいんかな、 と書いてみた。 で、まあ 1 ずつ配り出すとタイムアウトしちゃうよなー と 1 ずつ配り出したらループから出て一気に配るとかやったら example test 3 がコケる。 ああ貧乏人と金持ちの差が 1 以下になったら出ることにすればいいか… とやったら通る。
しかしこれでは 550 としては簡単じゃないだろうか… とアレコレとコーナーケースとか考えてみるも思いつかない。 びびりまくりつつ submit 。 うーんこんなカンタンでいいんだろうか…
900 開いてみるとまたしても簡単そうに見える。 しかしもう時間ないなぁ…と challenge 用にコーナーケースとか考えてたけど まぁもういいかと思う。
challenge は 500 で long long 越えるよねーって子を見つけて でもこのテストケースでいいんだっけ…とか考えてるうちに他の人に落とされた。 で 250 の数字の書き間違いっぽい子見つけて落とす。 いろいろながめていってもう一人見つけたけど、 それも慎重に確認してる間に他の人に落とされた。
終わってみるとびびりまくってた 250 も 550 も通ってて むなしくなった。 なんかもうちょっと大胆にやってたらもっと点数良かったのかー でもとりあえず2問正解とかできて良かった…とか思った。
(03:43)
250 適当にこんなもんでいいんじゃねと解いてみた。 あやしいなーと思ったけど、 なんか 250 だけじゃどうせ通らんだろうということで 深く考えず 500 に
500 はあれこれ考えてから終わる時間でテーブル作ればいいんだろうなぁ、 と書いてみたらどうも誤差が出る。 てことは分数とかそいう表記とかするんかなーとか思いつつ 実装する時間なくて終わり。 なんか他の人の見ると同じようなコードで通ってる。
challenge は比較的適当に1人ダメそうなのを落として、 ダメそうじゃないけどこの人レート的に落ちるんじゃねというのが落ちなくて、 80000*50*50 は時間的に無理じゃねというのも落ちなくて、 結局プラマイゼロだった。
で、 250 はなんかやはりよろしくなかったようだ。 system test で落ちて無事ぜろてんとなったのであった。
うむいい感じにひどい
(05:19)
↑で書いてた 500 は手元のテストだと
Test Case #5...FAILED (330 msec) Expected: { "0.328958","0.262915","0.184639","0.13123","0.0751863","0.0170713", } Received: { "0.31694","0.256831","0.196721","0.136612","0.0765027","0.0163934", }
って感じで結構誤差出るんだけど、 topcoder のサイトに今サブミットしてみたら通った。 コンパイルとテストくらいしてみたら良かったな
…と書いてて気付いた。 この Test Case #5 ってヤツは自分で追加したやつで Expected は適当な値なんだった。 それをすっかり忘れててなんか誤差デカいから困ったなあとか思ってたわけか。
(18:25)
GSL ががっかり決勝すぎてびっくりした。 ogsinca は cryolite さんに似てると思うんだよな…
あとなんか dia になかなかなれない。
今日は TCO やってみようと思う。 練習として去年の qual round 1 やってみたらやたら簡単だった。 250 と 500 が割とあっというまに解けた
なんか返信しないといけないメールがたくさんあるから とりあえずそれをやるか…
(22:56)
こういう画像があるので、 頑張ってどこが黒い点でどこが白い点かを推測しなさい、という問題。 プログラムは見たい行の答えを聞くことができて、 聞いた行は当然得点にならないので、 なるべく見る行数を少なくしつつたくさん正しい情報を推測できると良い。 フォントデータは与えられてるから、そのへんから推測する感じ。
僕は 4.5 行に一行ずつ開いてみて そこからそれっぽいアルファベットを適当に推測するとかそんな感じでやった。
当たり前だけど、 アルファベット一つに確定させる感じでやってたのはとりあえず良くなかったぽい。 @colun さんの twitter を読むに、 複数のアルファベットを使える可能性がある場合は、 ピクセルごとにそこが黒くなる確率を調べて そこが 50% 越えると黒とするとかが良かったようだ。 当たり前だ…
あと @colun さんがやったという、 前の行の情報から次開くべき行を確率的に調べる、 みたいなのはやった方がいいんだろうなーとは思ったけど、 どのくらい効くもんかなーというのが予想できなかったのと、 まあどうせ round 1 は通過できるだろうよ…と めんどくさくなって全然手をつけなかった。
いい問題だったと思う。 ただ解答のバリエーションが出にくい感じではあったかなぁ。 あんまりマジメにやってないのにそういうこと言うのも申し訳ない感じだけど。
まぁ round 2 行けると思うんで次から頑張ろうかと思う。 ていうか頑張らんと round 3 行けないよね…
(23:27)
linux x86-64 向けに作れないかなあと適当にごにょってみた。メモ
InstallCDT は x86-64 を target にするとうまいこといかんので、 install.sh の
CFLAGS="-m32" $sourceFolder/gcc-$gccVersion/configure
を
CC="gcc -m32" $sourceFolder/gcc-$gccVersion/configure
とかに変えたらとりあえずうまくいった。
Foundation, CoreFoundation, CoreServices, objc の xcodeproj に対して、 Linux-i386 な target を複製して Linux-x86_64 を作る。 で、 i386 になってる部分を全部 x86_64 に変える。 依存関係も作りなおす。出力先ディレクトリとかも変える。 Foundation に関しては march=i686 とかも消す。
これでたいていのファイルはコンパイル通るんだけど、 objc_msgSend 系の色々がアセンブリで書いてあるんだよな… 一見してやってることは簡単そうだからなんとでもなりそうではあるけど、 めんどくさい…
(21:53)
http://pumpkinsugar.posterous.com/llvm-coding-standards
LLVM/Clang はあんまり読むとかはしてないけど、 なんか追ったりはした… 主に ld-mac が起こす謎のクラッシュの追跡だったわけだけど。
なんか LLVM とか新しいプロジェクトだからコードが綺麗に違いない! と思ってみたら意外なことに色々よくわからんみたいなのがあって 余計がっかりみたいなのはある気がする。
それと LLVM が損してるのはやはりこう 変数名が大文字スタート関数は小文字スタートってのは 慣れてなさすぎるというのも。 普段はプロジェクト内でそろっていれば OK とか嘘ぶいてるクセに 結局そいうもんかなーとか。
にしてもなあ…
なんか普通に Tmp とか Str とかいう変数がそれなりに 長いスコープで使われてたりするし、 あとそもそも小文字大文字はルールが場所によって変わってるよね。 ループ変数だけは小文字とか、 ぱっと探して見つけたのでは include/llvm/ADT/APFloat.h なんかは構造体の名前、 enum 、 変数名と全て小文字スタート、 と思ったらたまに大文字スタートの変数もあるな…
それとファイルの場所特定しにくいのもすごい。
include/llvm/FooBar と lib/FooBar はだいたい対応するようになってるんだけど、 include/llvm/ADT はあるけど lib/ADT は無くて lib/Support に実装入ってるとか、 まあユーザのためにヘッダだけはとりあえず場所変えたけど 実装の場所いじる気力が無かったのかな…とか思うわけだけどひどいとおもう。
他には include/llvm/Attributes.h と lib/VMCore/Attributes.cpp が対応してるとかですね…
(23:19)
上のどれでも無いことをとりあえずやった…
https://github.com/shinh/w3m/commit/7eb2984ce3a61ceb7ec17b37a943c6c9ae3cbc7c
(09:29)
会社のホワイトボードに
[](){}();
とか書いてあって、 C++0x のラムダキモいとかいう話をしてたのかなぁと思った。 でもなんか思い出してみると記号だけで似たようなもん書ける言語ってのは いくつかあって、
->{}[] ->{}() (\()->())()
とかも書いておいた。 他もありそうだなぁと思ったけど思い出せなかった。
この手の syntax って最初に見た時はびっくりするけど、 慣れるとまぁなんでもないんじゃないかな。 むしろ
(funciton(){ // ... })();
みたいなコードがイディオム化している JS なんかだと、 これもうちょい短かった方が良かったんじゃないかな…とか思う。
(02:03)
http://d.hatena.ne.jp/hirosegolf/
この人が FizzBuzz 54B かつ今 TCO マラソンで僕の一個上にいる人かな…
(11:28)
これ難しいなぁ…と思いつつ 適当に書いたら意外と上の方に来た。 もうほっといても予戦は通れるかな… とも思うけどまぁみんなまだ様子見だろうしな…
うーんでも結構ここから大きく得点良くするのもむつかしそうではあるなあ
(11:32)
よく式を途中のローカル変数の情報つきで dump したくなる。
例えば
a = 42 b = 90 c = 20 dump{(a + b).to_f / c}
とかしたら
6.6 = ((a=42) + (b=90)).to_f / (c=20)
とか出る、というような。
Ruby なら書けるかなあ…ということで書いてみた。
https://github.com/shinh/test/blob/master/dump.rb
呼び出し方が
binding.dump "(a + b).to_f / c"
とかいう感じで文字列で呼ぶ感じになってしまったのが残念。 なんか構文木オブジェクトとか取れるといいんだろうね… あとインスタンス変数とかグローバル変数とかも対処した方がいいし、 途中のメソッド呼び出しとかも対応するといい気もするけど、 まぁこんなもんでもそれなりに良い気もする。
C++ ってか Boost::lambda ならこういうのできていい気がするな…
http://blog.livedoor.jp/sasata299/archives/51382345.html
を参考にさせてもらった
(16:51)
http://partake.in/events/8c2cd95b-b6d4-4d9f-917e-a98ba9aafd25
万が一 ksk さんが消えると人類は二度と 50B FizzBuzz に到達できないのではないか… とか意味わからんことを話してたりしたんですが、 まぁどっかで区切りをつけてどんなコードか見せてもらいたいもんですね… ということでページを作ってみました。 日程は特に反対が無ければ6月あたりかなぁと思ってます。
まぁ興味ある人は適当に参加表明していただければと思います。
しかし kinaba さんのせいで次の参加者の発言が規制されているな…
(21:55)
前 | 2025年 9月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ Gimite [> (funciton(){ > // ... > })(); そこでCoffee Script、なん..]