SRM349

教訓：桁あふれ怖い。

やっちまった･･･。

250pointer は場合分けしたら終わり。なのに long longの上限を激しく勘違いして自滅。
「64bit か…ふむ、2^60 と4bitだな。2^60 ≒ 10^18 だから 4 * 10^18 だ。ギリギリだ！
　しかもunsignedの引き算は負にならないかのチェック面倒くせえ！！！」
…と大変愉快な頭になっていたようです。テンパりすぎです、自分。

500pointer は普通のDP。全体的にlong longで扱わないといけないのに一時的な変数を一つintで宣言しちゃって、そこで桁あふれして自滅。

1000pointer は250に時間かけすぎたせいで時間切れ。

TopCoderがICPCとは決定的に違う点は一度submitすると、WAとかTLEといったレスポンスが無いこと。つまり、submit前に確実にコーディングできていなければならない点です。そして一問の差があまりにも致命的。

今回の結果は単純に、冷静さとコーディングスピード不足の現れでしょう。コードを書く段で、しっかりと仕様を満たしていることを確信できるだけの能力が必要です。まぁ、時間との勝負という点もあるのでその辺りのトレードオフが非常に難しいのですが、まずは正確に解けないと話になりません。

実際のソフトウェア開発では、ある程度自分でテストケースとかは作るにしても、基本的には十分なチェックが用意されているわけではないので、そういった素養は必要なものですし。

しかしアルゴリズムは思いついたのにしょーもないケアレスミスで自滅は正直悔しすぎる。

Exampleに対してはちゃんと正解を出すのにSystem Testを通らないというものの多くは境界条件の判定と桁あふれのような気がする。
long longが必要な問題なら、そこにChallengeの検証点を絞ってトライしてみるというのも悪くない戦略かな。

あと、TopCoderのエディタ上でのXKeymacsの挙動がオカシイ。
カットできなかったり、カットした文字列がペーストできなかったりしてすげぇストレスになる。
道具のせいにするつもりはないけど、もうちょいマシなコーディング環境を用意しないとなぁ･･･。