誤差ジャッジの不具合

[riantkb]

誤差ジャッジに以下の不具合があるように思われます。

• 想定出力が小数で提出の出力が整数の場合に WA と判定される
  • 例：想定出力が 2.0、提出の出力が 2 だった場合に WA となる
• 想定解が小数で 0.0 の場合に WA と判定される

原因としては、以下の関数に不備があると思っています

mojacoder/mojacoder-backend/judge-image/check.go

Lines 13 to 24 in 4337133

	func compareValue(answer string, solution string, accuracy float64) bool {
	_, err := strconv.Atoi(solution)
	if err == nil || err.(*strconv.NumError).Err == strconv.ErrRange {
	return answer == solution
	}
	numberC, err := strconv.ParseFloat(solution, 64)
	if err == nil {
	numberA, err := strconv.ParseFloat(answer, 64)
	return err == nil && math.Abs((numberC-numberA)/numberC) <= accuracy
	}
	return answer == solution
	}

• 提出解の出力が整数にパースできてしまう場合、文字列比較をしてしまうので、想定解が小数で提出解が整数の場合に WA と判定されているのだと思っています。
  • 想定出力と提出解の出力が共に整数にパースできるときのみ文字列比較、で基本的には問題なさそうなのですが、厳密には想定解が 1000000000、提出解が 1000000001 で誤差ジャッジをしたい時に困るかもしれないです（そんなことはなさそうですが）
• math.Abs((numberC-numberA)/numberC) <= accuracy で提出解の出力が 0.0 の時に NaN が発生し常に false となるので、想定解が小数で 0.0 の場合に 0.0 と出力すると WA と判定されるのだと思っています。
  • そもそも相対誤差だと 0.0 が解のときに誤差許容を行うことができないので、絶対誤差もしくは相対誤差が x 以下、とすべきなのかもしれません

[makutamoto]

対応遅れてすみません。
相対誤差について、
math.Abs(numberC-numberA) <= math.Abs(accuracy*numberC)
はありですか？

[makutamoto]

想定出力が小数で提出の出力が整数の場合に WA と判定される

これはcompareValueの引数が逆になっていました！
ごめんなさい。

[makutamoto]

想定出力と提出解の出力が共に整数にパースできるときのみ文字列比較、で基本的には問題なさそうなのですが、厳密には想定解が 1000000000、提出解が 1000000001 で誤差ジャッジをしたい時に困るかもしれないです（そんなことはなさそうですが）

これは僕も想定する必要はないと考えています。

[riantkb]

相対誤差について、
math.Abs(numberC-numberA) <= math.Abs(accuracy*numberC)
はありですか？

numberC が 提出されたコードの出力を数値化したものだとすると、inf と出力されたときに常に true になってしまいそうです。
多くの相対誤差の定義は （真値 - 測定値） / 真値 なのでそれに則って math.Abs(numberC-numberA) <= math.Abs(accuracy*numberA) とすると（想定解の出力が inf でない限り）おおよそは大丈夫そうな気はします。
ちなみに testlib での実装は以下のようになっているようです（本来はここまで inf や NaN などをチェックして、とやるべきな気もしますが、まぁコーナーケースが見つかるたび修正する、という方針でも問題ないと思っています）。
https://github.com/MikeMirzayanov/testlib/blob/f5b55f138709e97916f51bdb7a23baed941b5751/testlib.h#L411-L431

これは compareValue の引数が逆になっていました！

その場合、今のままだと今度は想定出力が 2、提出の出力が 2.0 のときに WA になりそうなので、どちらにせよ共に整数にパースできるときのみ文字列比較、などの何らかの変更は加える必要がありそうな気がします。
冷静に考えると、これだと普通の数え上げとかの問題で提出の出力が小数だと誤差ジャッジが走ってしまい嫌な気持ちになることに気づきました。どうすればいいのかはわからないです……（問題投稿時に誤差ジャッジかどうかを指定するしかない？）。

[riantkb]

ここまで書いて、上の方針で修正すると文字列の inf を出力して欲しいような問題のときに inf と出力すると WA になりそうなことに気づきました。これを回避するためにはやはり inf や NaN の判定をする必要があるかもしれないです。

[makutamoto]

その場合、今のままだと今度は想定出力が 2、提出の出力が 2.0 のときに WA になりそうなので、どちらにせよ共に整数にパースできるときのみ文字列比較、などの何らかの変更は加える必要がありそうな気がします。
冷静に考えると、これだと普通の数え上げとかの問題で提出の出力が小数だと誤差ジャッジが走ってしまい嫌な気持ちになることに気づきました。どうすればいいのかはわからないです……（問題投稿時に誤差ジャッジかどうかを指定するしかない？）。

現在は誤差ジャッジを使いたいときは解答を0.0のような実数形式で書いてもらうようにしています。
これでは不備があるのでしょうか？

[makutamoto]

ここまで書いて、上の方針で修正すると文字列の inf を出力して欲しいような問題のときに inf と出力すると WA になりそうなことに気づきました。これを回避するためにはやはり inf や NaN の判定をする必要があるかもしれないです。

INF判定追加します。

[makutamoto]

ここまで書いて、上の方針で修正すると文字列の inf を出力して欲しいような問題のときに inf と出力すると WA になりそうなことに気づきました。これを回避するためにはやはり inf や NaN の判定をする必要があるかもしれないです。

どうやらGoではNaNの入った条件はすべてfalseになるようなのでNaN判定はしません。

[makutamoto]

func compareValue(answer string, solution string, accuracy float64) bool {
	_, err := strconv.Atoi(solution)
	if err == nil || err.(*strconv.NumError).Err == strconv.ErrRange {
		return answer == solution
	}
	numberC, err := strconv.ParseFloat(solution, 64)
	if err == nil {
		numberA, err := strconv.ParseFloat(answer, 64)
		if math.IsInf(numberA, 0) {
			return (math.IsInf(numberC, 1) && math.IsInf(numberA, 1)) || (math.IsInf(numberC, -1) && math.IsInf(numberA, -1))
		} else {
			return err == nil && math.Abs(numberC-numberA) <= math.Abs(accuracy*numberC)
		}
	}
	return answer == solution
}

こうしてみました

[riantkb]

現在は誤差ジャッジを使いたいときは解答を0.0のような実数形式で書いてもらうようにしています。
これでは不備があるのでしょうか？

不備はなくて、想定解が小数点以下を必ず固定桁出力するようにしていなかった場合に、答えが整数となる場合にのみ誤差ジャッジが行われない、という発見されづらい不具合が埋め込まれた問題が生成される可能性を危惧しての発言だったんですが、まぁ現実問題としてそのようなケースを救う方法はないという結論になったので問題ないです。

どうやらGoではNaNの入った条件はすべてfalseになるようなのでNaN判定はしません。

（このような問題があるかどうかは置いておいて、）inf のときと同様 NaN という文字列を出力してほしい問題でどうあがいても AC が取れない、という状況になりそうな気がしているので、inf のついでに NaN の判定も追加してしまうのが良いかなぁという気持ちではいます。

[makutamoto]

追加しました。

[makutamoto]

おそらく問題は解決したのでCloseします。