競技プログラミングに関する TIPS 本です。
kanpe777 さんから借りて読みました。
印象に残っているのは
- 競技プログラミングはネトゲである
- float ではなく double を使う
- 定数倍高速化はムダ
- 100, 300, 600, 1000
- コーディング規約
- コードの綺麗さ
- 絨毯爆撃
- Editor な話で Vim が無い
- 摂動
- 自作ライブラリ、他人の自作ライブラリ
- 煩雑なデータ構造へのアクセサ
それぞれについてちょっとコメントすると
競技プログラミングはネトゲである
- みんなが集まってクエスト(問題)を解いていくから、と。なんかそれっぽい。
float ではなく double を使う
- 精度の関係で double 安定らしいです。
定数倍高速化はムダ
- これはちょっと耳が痛い話。
- 初心者がやりがちらしい話らしくて、定数倍程度のちまちました改善は基本的にムダらしい。
- 計算量を見直すレベルじゃないとダメだとか。
100, 300, 600, 1000
- 競技プログラマには解いた問題によって実力の壁があるんだとか。
- それが 100, 300, 600, 1000 らしくて、すごい方々は1000とか解いているらしい。
- 私は100も解いてない。うーむ。
コーディング規約
コードの綺麗さ
- 競技プログラミングのコードは基本的に書いて終わりだから、綺麗さをどうしようかという話。
- 競技プログラマのコードは汚いんじゃないか、みたいなイメージもあったりなんだりらしいけれど、競技のコードとそれ以外のコードは分けよう、とか。
- あと、チーム戦なら競技でもちゃんと書いた方が良いし、自分のためにもちゃんと書こう、みたいな。
絨毯爆撃
- これは知らなかった。というかその発想は無かった。
- 撃墜フェーズで良いコーナケースを思い付いたら、それでひたすらに爆撃していくらしい。
- 大量得点 or 大量失点 の大博打らしいです。
Editor な話で Vim が無い
- 補完の関係では Visuatl Studio, Eclipse とか、構文チェックでは Eclipse, Visual Studio, Emacs + flymake とかが紹介されてました。
- Vim も Makefile 書けば quickfix に syntax error 残るし、 quickrun とか quickrun + watchdogs とか syntastics とか入れたら捗りそうなのになー、とかって私見。
摂動
- 実数を扱う時には誤差を考慮したりするのだとか。知らない世界でした。
自作ライブラリ、他人の自作ライブラリ
- 競技で頻繁に使うたコードはライブラリにしたりするのだとか。
- 他人のライブラリと比較したり自分なりのアレンジを作ったりなんだりするらしい。
煩雑なデータ構造へのアクセサ
- これは良いなと思った。
- クラスを作るようなサイズで無い(とか時間が無い)構造体を定義する時とかに、それにアクセスするためだけのメソッドを定義する、というもの。
- triple の変わりの pair pair だと hoge.first.first とかになって分かりづらいので accessor(my_triple hoge) { return hoge.first.first } とか
他にもいろいろありましたがこんなところで。
細かい tips もあったりしたので、簡単に手に入るなら手元の置いておいても良いのかな、とか思いました。
0 件のコメント:
コメントを投稿