Test with output_checker

[beet-aizu]

出力が複数ありうる系のスペシャルジャッジに対応してほしいです

例： https://judge.yosupo.jp/problem/scc https://github.com/yosupo06/library-checker-problems/tree/master/graph/scc

[kmyk]

「出力が複数ありうる系のスペシャルジャッジに対応」とは、どのようなインターフェースのものを考えていますか？ 実は、回答側のプログラムの中でその出力の前後に assert を置いて (https://online-judge-tools.readthedocs.io/en/master/introduction.ja.html#id5) テストファイルとして *.in だけを指定することで、擬似的にスペシャルジャッジを再現できます。実用上はこれで十分だと考えているのですが、どうでしょうか？

ジャッジプログラムを書いてそれを食わせる形式 (つまり、入力ファイル + 期待される出力やその他の情報を含むファイル + 実際の出力ファイル のパスをそれぞれを受け取って正誤判定をするジャッジプログラムを (ユーザが) 書き、それを $ oj t -c ./a.out --judge "python3 judge.py" のように指定して利用する形式) も考えられますが、ユーザにとってかなり面倒なはずです。少なくともコンテスト本番中に使う人は誰もいなさそうです。 なので現状はあまり実装する気は起こっていません。必要なら追加の説明をして私を説得してください。もちろんプルリクが来ればマージします。

[beet-aizu]

可能であれば一つ出力してください ( http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=2997 や https://codeforces.com/contest/1214/problem/G ) 系は可能かどうかが out ファイルなしでは判別できないと思います。

形式としてはまさにそんな感じのものを考えていました。サンプルを試すためだけにoutput_checkerを書くかと言われると微妙なのは確かにそうですね。

時間ができたら実装してプルリクを投げるつもりです。

[kmyk]

現在のジャッジの比較部分のモードは「通常」「行ごと」「誤差」と3個あって if 文で頑張ってるけど、class OutputComparator みたいなのを作ってそのサブクラスとして切り出すべきな気がしてきました。 ここをきれいにリファクタリングできれば、スペシャルジャッジ対応は数行書くだけになるし、よくあるパターンは checker を書かせるのでなく組込みで対応できそう。たとえば http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=2997 の形式 (Yes / No を出力し、さらに Yes ならその後ろに何か) の形式ぐらいは簡単に使えたい。

[fukatani]

@beet-aizu @kmyk #584でレビュー進行中なので、もし議論に加わりたければ加わってください。