Closed WATLE closed 2 years ago
なお、testではなく、 本体コードでの 0に近いかの判定はそのままにしておいてます
この解決策として、test/util/util.hppにepsの定義を移動し、test/util/util.hppをincludeすることにして、テストコード側ではepsを定義しないようにする、というのが考えられますがどうでしょうか?
test内容によってepsはピンキリなので、 一律はちょっと... ?
1e-10 のやつも結構見る DensityMatrixTestには1e-8 もあった
でも確かにそれでもいい気もします
よく見たらかなりの割合で1e-12と1e-10になったし、 統一してもよさそう
epsを毎回定義しているのは混乱のもとになると思うので、統一する方が嬉しいです。
とりあえずざっと見て全部計算誤差による理論値とのズレを主張するものであることを確認しました。
これを統一することには賛成ですが、utilityに置くならもう少しユニークな名前を採用したほうがいいんじゃないかと個人的に思います(これは適当ですがCALC_EPS
とか)
DensityMatrixGeneralGateTest.TwoQubitDepolarizingTestで落ちるのは計算誤差ですが、現状のテスト落ちの多くはサンプリングの偏りなどで生じる確率的なものなのでそっちに対する統一的な対応(「とても運が悪くてズレる」のは仕方ないのでそれがめったに(10回中2回など)起こらないことを示す)もしていきたいですね
LGTMです!
utilityに置くならもう少しユニークな名前を採用したほうがいいんじゃないかと個人的に思います
test配下に閉じたutilityなので、まぁこの名前でいいかなと思いました。。
誤差が1e-15,1e-14だったのを1e-12に変更しました 誤差が1e-12より緩いのはそのままです