はじめてのにき(2011-05)

2011-05-05

_ LLVM の謎

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)

[ツッコミを入れる]

Foundation, CoreFoundation, CoreServices, objc の xcodeproj に対して、 Linux-i386 な target を複製して Linux-x86_64 を作る。で、 i386 になってる部分を全部 x86_64 に変える。依存関係も作りなおす。出力先ディレクトリとかも変える。 Foundation に関しては march=i686 とかも消す。

これでたいていのファイルはコンパイル通るんだけど、 objc_msgSend 系の色々がアセンブリで書いてあるんだよな… 一見してやってることは簡単そうだからなんとでもなりそうではあるけど、めんどくさい…

(21:53)

[ツッコミを入れる]

2011-05-12

_ TCO マラソン Round 1 終了

こういう画像があるので、頑張ってどこが黒い点でどこが白い点かを推測しなさい、という問題。プログラムは見たい行の答えを聞くことができて、聞いた行は当然得点にならないので、なるべく見る行数を少なくしつつたくさん正しい情報を推測できると良い。フォントデータは与えられてるから、そのへんから推測する感じ。

僕は 4.5 行に一行ずつ開いてみてそこからそれっぽいアルファベットを適当に推測するとかそんな感じでやった。

当たり前だけど、アルファベット一つに確定させる感じでやってたのはとりあえず良くなかったぽい。 @colun さんの twitter を読むに、複数のアルファベットを使える可能性がある場合は、ピクセルごとにそこが黒くなる確率を調べてそこが 50% 越えると黒とするとかが良かったようだ。当たり前だ…

あと @colun さんがやったという、前の行の情報から次開くべき行を確率的に調べる、みたいなのはやった方がいいんだろうなーとは思ったけど、どのくらい効くもんかなーというのが予想できなかったのと、まあどうせ round 1 は通過できるだろうよ…とめんどくさくなって全然手をつけなかった。

いい問題だったと思う。ただ解答のバリエーションが出にくい感じではあったかなぁ。あんまりマジメにやってないのにそういうこと言うのも申し訳ない感じだけど。

まぁ round 2 行けると思うんで次から頑張ろうかと思う。ていうか頑張らんと round 3 行けないよね…

(23:27)

[ツッコミを入れる]

2011-05-14

_ 日記

GSL ががっかり決勝すぎてびっくりした。 ogsinca は cryolite さんに似てると思うんだよな…

あとなんか dia になかなかなれない。

今日は TCO やってみようと思う。練習として去年の qual round 1 やってみたらやたら簡単だった。 250 と 500 が割とあっというまに解けた

なんか返信しないといけないメールがたくさんあるからとりあえずそれをやるか…

(22:56)

[ツッコミを入れる]

2011-05-15

_ mixC++ Code Golf

https://sites.google.com/site/mixcgolf/

そうか ideone に丸投げって手があるのか…!

(00:28)

_ TCO qual 1

250 適当にこんなもんでいいんじゃねと解いてみた。あやしいなーと思ったけど、なんか 250 だけじゃどうせ通らんだろうということで深く考えず 500 に

500 はあれこれ考えてから終わる時間でテーブル作ればいいんだろうなぁ、と書いてみたらどうも誤差が出る。てことは分数とかそいう表記とかするんかなーとか思いつつ実装する時間なくて終わり。なんか他の人の見ると同じようなコードで通ってる。

challenge は比較的適当に1人ダメそうなのを落として、ダメそうじゃないけどこの人レート的に落ちるんじゃねというのが落ちなくて、 80000*50*50 は時間的に無理じゃねというのも落ちなくて、結局プラマイゼロだった。

で、 250 はなんかやはりよろしくなかったようだ。 system test で落ちて無事ぜろてんとなったのであった。

うむいい感じにひどい

(05:19)

_ qual 1

↑で書いてた 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)

[ツッコミを入れる]

2011-05-18

_ SRM504.5

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)

[ツッコミを入れる]

2011-05-19

_ TCO Qual 2

呑み会で適当にやった。 10分くらいでバッテリ切れるからその間に1問解ける予定だったんだけど、問題を読んでる最中にバッテリ切れてしまった。問題開いちゃったので0点。

レートが青くなってしまったよ

(23:53)

[ツッコミを入れる]

2011-05-23

_ kwenwl VM なんちゃら

http://atnd.org/events/15330

行ってきた。なにやら色々と面白いことをやってる人がいるなあと勉強になった。特にネットワークまわりとかは相変わらず勉強がたりなさすぎてよくわからないことが多かった。

個人的に興味というか比較的知ってる分野に近くて印象に残ったのは「アセンブラ大集合」と「目grep入門」があったと思う。

前者の方はアセンブリの見た目から CPU の一定のクセを読むみたいな話でこういうのはわかった気ができてたいへん楽しい。個人的にもこういうのを作ってみたりしていた。

http://shinh.skr.jp/h/?FizzBuzzAsm

追加大歓迎

後者の方はそのレベルでは全然ないけど、 Python challenge lv5 を Python の知識なく解いたあたりが近い方面のアレだったかなぁとか思った。

http://d.hatena.ne.jp/shinichiro_h/searchdiary?word=python%20challenge

他にも ICFP の問題から画像取り出したりとかで似たような方法論を使ったかもしれず。

自分のした発表についてはかなり反省するものがあった。基本的にこの手の発表をするモチベーションとして

自分のやったことを俺スゲーと自慢する

っていうのは間違いなくあって、こういうののやり方としてはいくらでもあるわけだけど、なんとなくコレだけでは良くないと思っていて、

なんだこの程度のことでそれができるのか。それなら俺にもできるぜ、と聴衆に思わせる
- ことによって自分にとって有益なフィードバックを得る
- さらに自分には思いにもよらない発展があればさらに良し

っていうのは割と重要なアレとしてあると思う。

今回は聞き手がわかってそうなところをすっとばしまくったので、後者の方のアレがイマイチだったように思う。

というのはなにか若い人と後で話して、若い人「なんとなくとか言ってたけどれあれ大変ですよね」若くはないと言っても当たり障りのなさそうな人「そうなんだけどあれはやるべきあたり前の事を順番にやってるだけなんだよ」とかそいう会話を少しして、後者の方の人と僕のやったことが当たり前のことだという理解を共有できていたことに強い喜びを覚えるとともに、前者の方の人にアレがいかにどうでもいい当たり前のことであるかが伝えられてなさそうだったことに残念に思ったのであった。

ちょっと考えると後者のような人は何を喋っても理解してくれるわけで、前者の人にこそ「僕がこの問題についていくつかある選択肢のうちこの選択をした結果、現状の当たり前の結論に落ち着いたか」ってことを伝えたかったんじゃないかなぁとか思う。

発表時間が短いということでアプローチとかはざっくりと削ってしまって、何を話そうかと考えた結果僕が苦労したところを適当に話すみたいな感じになったのだけど、しかし基本的なことをもっと説明することもできたんじゃないかとちょっと残念だった。

こいうことを思ったのは、こいう現象ってのは会社でなんか喋る時とかにもっとひどくて、会社の人の優秀さに頼り過ぎてて説明を省略しすぎてる感があるなぁ… とか思ったこともあったのであった。

しかし一方で俺SUGEEは一定したいってのはあるので、なかなかこういうのはバランスが難しくて面白い問題だと思う。なんかで読んだ、80%くらいは着いてこさせて、 20%くらいで聴衆無視して自分が楽しいだけの話をする、っていうプレゼン術はなにか色んな意味でよい気がする。

ところで今回のプレゼン資料はここにあります

http://shinh.skr.jp/slide/ldmac2/000.html

まとめると、このプレゼンに対する想定反論として、そんなもん当たり前じゃねえよ! ってものがあって、それはそれで俺 SUGEE に成功しているという意味では嬉しい面もあるのだけど、しかし共有ライブラリとかローダーとかの仕組みについてマジメに考えたことのある人に取ってはやはり当たり前のことで、まさに「やるべきことをやったらなんとなく動いた」のであって、その当たり前さの感動を伝えられない悲しさもあり、というようなそういう。

いや当たり前さの感動みたいなものはあると思うんだよね。仕様に決められてる通りのプロトコルを喋るクライアントを書いたら動いた時の感動というか…

まあなんかプレゼンってのは面白いよね…と思う

(01:15)

_ ↑

まあそもそも眠くてしょうがなかったとかいう根本的な問題があって現実的にはそっちのマイナスの方がはるかにヒドかった可能性があるという話があると思う。

しかし僕が考えたいのは、そういう現実の話じゃなくて、「一体何が楽しくて僕はあからさまに得意でないプレゼンとかやってみてるんだろうか」とか「僕の伝えたいことを考えたところ、プレゼン資料を用意する時に考えるべきことはなんだろうか」とかそういう形而上的というかそいうメタなことが考えたいのであって、「人を感動させるプレゼン術」とかそのへんにはイマイチ関心を持っていないのであった。いや関心はあるのだけど、自分でやってみようとかはあまり考えてないというか…

(01:22)

[ツッコミを入れる]