に参加してました。と言っても最低限のコードを書いて終わったのでガッツリ参加したというわけではありませんが、 全体を通しての感想を残しておきます。（どちらかというと要望）
運営も自虐するぐらいにはグダっていたと思います。
共通
アナウンス無しの延期は止めてほしい
- OO 日に更新予定です。 -> OO 日に特に何も無し
- XX 日に公開予定です。 -> XX 日に特に何も無し
このパターンが多かったです。当日でも良いので延期のアナウンスがあったほうが嬉しいです。（アナウンス無しは「もしかして放置されている？」と不安になります）
ジャッジプログラムや問題文の更新が多い
正直多すぎました。特にコンテストの序盤とかはちょっとジャッジプログラムを読み進めるだけでもすぐ問題文との矛盾点が見つかるぐらいには多かったです。4000行近くのジャッジプログラムだったので不具合が多いのは仕方ないと思いつつ、コンテスト終了直前まで定期的に修正が入るのはさすがにきつかったです。
ジャッジプログラムが読みにくい
不要な ; やif (false) のようなコードが多く、ジャッジプログラムを読むときには毎回消しながら読んでいました。
エラーメッセージが不親切
コンテストタント側のプログラムが何かしらの制約にひっかかって落ちた時にエラーメッセージ無しに exit(1); だけで終わらせていたので原因を突き止めるのに時間がかかりました。
（自分でエラーメッセージを追加してました）
ジャッジプログラムの計算資源を別で管理して欲しい
今回制限として「実行時間制限: 300 sec」「メモリ制限: 3072 MB」とあったのですが、正直何の指標にもなりませんでした。 というのも今回、コンテスタント側はジャッジ側にクエリを投げることで仮スコアを得ることが出来たのですが、 クエリの処理にかかる「時間」と「メモリ使用量」がこの制限に含まれていました。そのため、コンテスタント側で制限を守っていてもジャッジ側の処理でそれを超えてしまう可能性がありました。
様々なケースが考えられる中でテストケースのジェネレータも無いままジャッジ側のメモリの最大使用量を見積もるのは面倒でした。
「時間」に関しては A 問題だと、グリッド配置を決めたら後はジャッジプログラムが処理するだけなのですが、例えば 280sec 使って配置を決めても、ジャッジ側の処理で 21 sec 以上使ってしまうとアウトなので、コンテスタント側では「この配置だと XX sec 使用する」みたいな予測を行って、余裕をもたせてプログラムを終了させる必要がありました。
コンテスト序盤とかはほぼ何もしてないサンプルコードでも 90 sec 近くかかっていました。（改良版が出て 20 sec ぐらいには下がりました）
テストケースジェネレータの提供もしくは生成方法の擬似コード表記
今回 pretest が 3件だけだったので、システムテストが重要になってくるのですが、システムテストでどのようなパラメータになるのかがちょっとわからなかったです。 例として
(例: 系統から電力を購入することによるペナルティ(alpha_buy_ele やalpha_buy_env)が大きいケース、w_acc, w_trans, w_ele, w_envのいずれか1つが小さくなるケース)
とあり「alpha_buy_ele や alpha_buy_env は制約内でランダムに決められる値ではないのか」「いずれか1つが小さくなるケース ということは他のパラメータは同一の値なのか」とか色々質問したい事項がありました。
将来的な技術動向や政策動向を考慮し、特定のアセットや条件などが有利になるケースを含むように選択
と書かれてしまうと正直もう個人的にはお手上げでした。
相対スコアの導入
今回大まかに「輸送スコア」「電力スコア」「災害対応スコア」とカテゴリー別のスコアがあったのですが「輸送スコア」で得られるスコアが他のスコアに比べて大きかったので「輸送スコアを得意とする人」と「電力スコアを得意とする人」を比較した時に「輸送スコアを得意とする人」が有利となってしまうので、各スコアを平等に評価するのであれば相対スコアで比較したほうが良いと思いました。
A 問題
サンプルコードの充実化
A問題のサンプルコードが簡素なシェルスクリプトだったのは不親切かなと思いました。 問題自体が多くの入力を受け取る必要があったのでサンプルコードを書くコストもそれなりに高かったと想像できるのですが
なお、初心者向けのサンプルコードを用意しているので、必要に応じて参照して欲しい。
この文言からの
#!/bin/sh echo end echo 2 echo 1000 10000 echo 1 3 echo 1 echo 1 3 echo 1 echo 1561 20000 echo 1 2 echo 1 echo 1 3 echo 1 echo 2 echo 1000 100000 1 echo 1561 100000 1 echo submit 9999 1
このコードは少し不親切かなと思いました。最低限入力を受け取るあたりのコードは欲しかった気がします。
車両アルゴリズムの説明
A 問題はグリッドと EV の配置を決めたら後はジャッジ側で事前に用意されたアルゴリズムによって処理が行われていくのですが、この車両アルゴリズムについての説明が一切無いのでジャッジプログラムを読んで理解する必要がありました。
A 問題の目的として「安定した電力供給に加えて円滑に輸送サービスを提供するために適切なナノグリッドの配置を考えて欲しい」とあるので、車両のアルゴリズムについてはある程度出題者側から説明が欲しかったです。
B 問題
ジャッジプログラムに計算資源を取られること以外は特に不満はありませんでした。
