ふるた技工所(てっこうしょ)

ここしばらく、日記がサボりがちになっている。プログラミングスキルチェックサイト(Paiza)に没頭していた。100 点は目指さない。「好きにプログラムを作ってみよう」。という姿勢だ。もう少し「好き」を具体的に書くと、

• 問題文ある入力範囲の制限はできるだけ取り除く
• あまり面倒でなければ Secure coding をしてみる
• 入力エラー、内部ロジックエラー、メモリ不足など不意な状況もなるべく検出する
• 時には over kill のアルゴリズムを投入してみる。そして、逆もあり素朴でのんびりと動くアルゴリズムで臨むこともする
• ちゃんと動くことを目標にする。時間が掛かってもよいから、テスト入力は 100% 期待値と一致させる
• 「たまには bash で...」と思ったら、まだちゃんと動いていないみたい

いくつかの問題で統計された正解率が極端に低い問題が有った。なんでだろう。試しに解いてみることにした。おおよそ次の傾向があることが分かってきた。

• そもそも問題文に誤りがある
• 入力に可変要素がある(特にテキスト入力の列方向)
• ステートマシンの様に内部記憶をもち、それを順次変化させる必要がある
• マシンイプシロンなど環境に依存性があり、作ったコードが題意を満たすかどうか証明するのに時間がかかる(マシンイプシロンは DBL_EPSILON などで取得可能だ。厳密にいえば環境依存なので、調査する必要があるし、値をなるべく真値に近く扱える実装が必要だ)

全部言及すると長くなる。何かネタが無い時の機会に回そう。

「そもそも問題文に誤り」は出題側は気付かないのだろうか？正解率は低く回答時間が長い。他の問題の傾向と比べて突出してる。しばらくして、「何かおかしい」と気付くはずだ。

表に出す前(本番環境稼働させる前)に、レビュー、テストを十分にするのが教科書に書かれていることだ。誤りもそれほど難しい論理証明をせずとも発見できるものだった。

どうやって問題作ったのかな。何も考えずにどこかのサイトのコピペ？ コピペ技術者で十分というのはちょっと悲しいな。