なんか問題作るの手伝うとか言いつつほとんど何もしなかったものの私の出題の問題もあるしなーという微妙な状況だったのですが、良ければテストしてちょ、と始まってから言われたので、適当に参加した。ちょうど入賞圏外の4位というのはうまいところにおさまったもとは言うものの、とにかく気持ち悪い。やっぱやるなら会社とか休んで死力を尽くすべきだなーと思った。
http://felicity.iiit.ac.in/tle/
問題説明は kinaba さんがしてくれてるのでそのへん参照。
http://www.kmonos.net/wlog/106.html#_1924100217
PALIN1
kinaba さんの書いておられる通り筆算的にすればいいんだろうなーと思ってちょっとやってみたけどすぐ通らなかったのでまぁいいや的な。時間がなかったというかんじ。
PALIN2
ていうか gets の引数無くても良かったんですかねこれ… for 2 つを 1 つにするよくある力技で同点にしてるって感じですかね。
主催側が PALIN2 解けてないとか書いてたけどこんなもん見してくれたら瞬殺で解いたし、 checker のバグも取れただろうに。まぁ主催の人々コンテストやりすぎにつき忙しかったんだろうししょうがないと言えばしょうがない。
PREP
出題しておきながらどう解いたらいいかとかあまり深く考えてなかったので、みんなすごいなーという感じ。適当に出したものの、みんな解答がだいぶ違って興味深いから割といい問題だったのかもしれず。プリプロセッサゴルフは真剣に考えても良い課題な感じがする。あとで読む。
あとそういえば空白入れてもいいって制約は、別に無くても問題ないんだけど、間に空白を入れずにつなぐのって結構むずかしいから、その知識がなくて挫折ーってのをふせごうと思ったんだけど、実際のところどうだったのかな。
CARM
やりたかったなー。時間なし。
COMP
毎度ながら圧縮下手だな。後でちょっと調べる…というか omoikane 先生ちょっとすごすぎるんじゃないのかこれ。あとで読むべき。
SHORTEN
つまりこれは、問題の入力 50 個に確定してたのかな? なんかこの程度の問題でこれだけ差がついてるのが不思議感があったのでそれなら割と納得。いずれにせよゴルフ不足。
KEY
私もこの手の問題好きなのでそれなりにやって何度も main 再帰だけの形に持って行ったんですけど、 GCC がちっとも末尾再帰の最適化をやってくれないもんだから大変困った。ある意味スタックゴルフの問題という感じで面白いなーとか思っていました。
途中 for の数減らす方法としてやってみた
__builtin_popcount((i&4095)+(i^i>>7&4096)+(i^i>>5&8192)+(i^i>>3&16384)+(i>>1&32768))
とかいうのは割とお気に入りだけどだからどうした!
どうでもいいけど
#\
define F() for(
とかやればチートできるぜ、 checker は cpp -dM して #define の有無を確認すべき、っていうのは報告したもののなおらなかったのかな。私の記録がそのチート確認の時のになってる…まぁいずれにせよこの付近の点数は出てたはず…このチートアリなら
#\ define F(A,B,C) f##or(A;B;C)
的なことやればかなりいい点数出たんじゃないですかね。
あとこの問題って asm で回避するという素敵な策もあるんじゃないかと思ってるんですが、ちょっと長くなっちゃうかな…
CQUINE
いつも通りに quine 書いてた。上 2 人は両方とも賢いなー。 680997 で double quote 回避もすごいし、全文 define もえらい。全文 define のパターンはあんま書いたことなったから発想に登らんかったなー。 notogawa さんにはゴルフ力でも普通に負けてたなぁダメだ。
この問題は 2 つの問題がもうちょっと似てない方が面白かったんじゃないかなーとか思った。
まとめ
来年はちゃんと参加する!
