はじめに [ プログラミングコンテストとは？ ]

まず、どのようなことを行ったのか簡単にご説明します。

問題ファイル

1行につき以下の形式で問題が書かれている
- [行インデックス,列インデックス]+[行インデックス,列インデックス]=
  - 行インデックスは0始まり
  - 列インデックスは0始まり
空行は存在しません。
行インデックスと列インデックスが範囲外の地点を指す可能性は考慮しなくて良い

入力ファイルと問題ファイルと結果の例

入力ファイルが3x3で

1,5,3
2,8,1
9,2,6

で問題ファイルが、

[0,1]+[2,2]=
[2,0]+[1,1]=

の場合は、結果は以下のようになります。

11
17

パターン

入力ファイルと問題ファイルの組み合わせで以下の3つのパターンが存在します。

SMALLパターン
- 入力ファイル: 100行100列。各要素の値は1〜100の整数
- 問題ファイル: 100個の演算式
MEDIUMパターン
- 入力ファイル: 10,000行10,000列。各要素の値は1〜10,000の整数
- 問題ファイル: 100個の演算式
LARGEパターン
- 入力ファイル: 10,000行10,000列。各要素の値は1〜10,000の整数
- 問題ファイル: 10,000個の演算式

順位付け

以下のルールでランキングを競います

プログラムの開始から終了までの実行時間が短いものが上位
コンパイルエラーは失格扱い
実行中の例外は失格扱い
計算結果が誤っている場合は失格扱い

感想 [ 2021年入社 S.O ]

普段の研修では可読性を意識したコードを書くことがほとんどで、計算量や実行時間についてはほとんど意識せず（場合によっては計算量を犠牲にしてでも可読性を優先する）に書くため、研修で計算量や実行時間について考える機会が得られて嬉しく思いました。
また、ファイルの入出力について詳しくわかっていないままコンテストを迎えたため、この辺りの調査に多くの時間を取られてしまいましたが、実際には自身のタイムにさほど影響せず徒労に終わってしまった点が印象に残っています。
自身のタイムを更新するためには、ほとんど意味のない小さな改良に思える点でも軽視してはいけないことも学べました。
コードを改良していく際には、ローカル環境と提出先の環境で時間を計測して改良が有効かを判断していましたが、どちらの環境も実行のたびにタイムがぶれるため、判断が難しかったと記憶しています。
また、最終日にはサーバーが不調となり、実行時間が10倍くらいに増えてしまう事態になったのは残念だったと思います。