1

仕様に合わせて機能する信号処理ライブラリがあります。ただし、リファクタリングに適した場所をいくつか特定しました。しばらくの間、単体テストをワークフローに組み込むつもりでしたが、これは重要なコードを試す良い機会のようです。これは、リファクタリング後に出力がほぼ同一であることをテストできるようにするためです。

私はテスト フレームワークとしてcatchを試していますが、(私が収集できるものから) すべてのテスト フレームワークはオペレーターからの結果に依存しているため、この詳細は無関係かもしれません。

REQUIRE(i_x == 2)

ただし、浮動小数点データでは、何らかの形式のエラー境界チェックが必要です。. 

const float target = 2.000f;
const float tolerance = 0.000005f;
const float err = target*tolerance;
REQUIRE( (f_x > target-err) && (f_x < target+err) )

これは、記述されたすべてのテストですぐに醜くなるため、もちろん、指定された , をパラメーターとして返す (テンプレート化された) グローバル関数をbool作成xできtargetますtolerance。

これは他の誰もがこれを行う方法ですか？これはベストプラクティスですか、それともトリックがありませんか?

4

1 に答える 1

4

テストはコンテキストに非常に敏感です。あなたが提案するテストは、相対誤差をテストします。本質的に、この特定の状況では、次のように主張しています。

  • 通常の許容可能なコード変更では、結果に比べて小さな偏差が各結果に生じる場合があります。
  • バグは、結果に対して小さくない偏差を生成する可能性があります。

一般に、2 番目のアサーションは安全であることが多いと思います。「ランダムな」コード変更は、少なくとも一部の値に大きな違いをもたらす可能性があります。ただし、浮動小数点を適切に処理するアプリケーションが存在する可能性があります。その場合、わずかな偏差が仕様外の結果を引き起こす可能性があります。たとえば、正しい結果とわずかに異なる結果を返すアークサイン ルーチンがあるとします。正しい結果が 1 の場合、この関数は 1+2 -23を返します。後で、この結果 x は次のような式で使用されます。sqrt(1-x*x). この式は、アークサインのすべての数学的に正しい値 (実数入力の場合) に対して実数ですが、x が 1 よりわずかに大きい場合、負の数の平方根を取得しようとするため、エラーが発生します。したがって、2 番目のアサーションがアプリケーションに適しているかどうかを判断する必要があります。

最初の主張はもっと疑わしい。浮動小数点演算のエラーの原因は、常に最終結果に比例するとは限りません。たとえば、ある入力信号の離散フーリエ変換 (DFT) を取ることを検討してください。ほぼすべての出力数値について、各入力数値がある程度寄与します。個々の出力数値の中には、偶然にもゼロに近いものがあります。ただし、それらのエラーは、入力の大きな数値に比例する場合があります。したがって、そのような出力数に相対誤差のテストを適用すると、バグの誤った兆候が生成されます。代わりに、入力によって何らかの方法でスケーリングされるエラーを許可する必要があります。

于 2012-09-13T14:14:31.480 に答える