`Vector <float> .Equals`は再帰的である必要がありますか、それともIEEE 754セマンティクスに従う必要がありますか？

浮動小数点値が等しいかどうかを比較する場合、2つの異なる方法があります。

• NaN一致する、それ自体に等しくないIEEE 754仕様。
• NaN等価関係の定義に不可欠な反射性の数学的特性を提供する、それ自体に等しい

C＃（にIEEE浮動小数点型に内蔵floatし、doubleIEEEのためのセマンティクス従う）==及び!=（等リレーショナル演算子<）が、ための反射性を確保しobject.Equals、IEquatable<T>.Equals（およびCompareTo）。

ここで、float/の上にベクター構造体を提供するライブラリについて考えますdouble。このようなベクトル型は過負荷になり==/ !=およびオーバーライドobject.Equals/ IEquatable<T>.Equals。

何皆に同意すると、そのある==/ !=IEEEセマンティクスに従ってください。問題は、そのようなライブラリーがEquals再帰的な方法で、またはIEEEセマンティクスに一致する方法で（等価演算子とは別の）メソッドを実装するかどうかです。

のIEEEセマンティクスを使用するための引数Equals：

• IEEE 754に準拠

• SIMD命令を利用できるため、（おそらくはるかに）高速です。

  私は、スタックオーバーフローについて、SIMD命令を使用して再帰的等式をどのように表現するか、およびそれらのパフォーマンスへの影響について、別の質問をしました。浮動小数点の等値比較のためのSIMD命令

  更新： 3つのSIMD命令を使用して効率的に再帰的等式を実装できるようです。

• のドキュメントでEqualsは、浮動小数点を使用する場合に再帰性は必要ありません。

  次のステートメントは、Equals（Object）メソッドのすべての実装に当てはまる必要があります。リストには、x、y、およびznullではないオブジェクト参照を表します。

  x.Equals(x)true浮動小数点型を含む場合を除いて、を返します。ISO / IEC / IEEE 60559：2011、情報技術-マイクロプロセッサシステム-浮動小数点演算を参照してください。

• floatを辞書のキーとして使用している場合は、罪の状態にあり、正常な動作を期待するべきではありません。

再帰的であるという主張：

• それはを含む既存のタイプと一致だSingle、Double、TupleとSystem.Numerics.Complex。

  Equals再帰的ではなく、IEEEに従うBCLの前例は知りません。カウンターの例としてはSingle、Double、TupleとSystem.Numerics.Complex。

• Equals主に、反射性に依存するコンテナと検索アルゴリズムで使用されます。これらのアルゴリズムでは、動作を妨げる場合、パフォーマンスの向上は重要ではありません。パフォーマンスの正確さを犠牲にしないでください。
• これは、すべてのハッシュベースのセットや辞書、壊れるContains、Find、IndexOfさまざまなコレクション/ LINQ、セットベースのLINQの操作（上Union、Exceptデータが含まれている場合など）NaNの値を。

• IEEEセマンティックが受け入れられる実際の計算を行うコードは、通常、具象型で機能し、==/ !=（またはより可能性の高いイプシロン比較）を使用します。

  ジェネリック演算が必要なため、現在ジェネリックを使用して高性能計算を作成することはできませんが、これらはインターフェース/仮想メソッドを介して利用できません。

  したがって、遅いEqualsメソッドはほとんどの高性能コードに影響を与えません。

• IEEEセマンティクスが必要な場合、またはパフォーマンス上の利点が必要な場合に、IeeeEqualsメソッドまたはを提供するIeeeEqualityComparer<T>ことができます。

私の意見では、これらの議論は再帰的な実装を強く支持しています。

MicrosoftのCoreFXチームは、そのようなベクトル型を.NETに導入することを計画しています。私とは異なり、彼らは主にパフォーマンス上の利点のために、IEEEソリューションを好みます。このような決定は最終リリース後も変わらないので、大きな間違いだと私が信じていることについてコミュニティからフィードバックを得たいと思います。

IEEEの動作は正しいと私は主張します。NaNsはいかなる意味でも互いに同等ではありません。これらは、数値の答えが適切でない不適切に定義された条件に対応します。

ほとんどのプロセッサがネイティブでサポートしているIEEE演算を使用することによるパフォーマンス上の利点以外に、if if isnan(x) && isnan(y)、then と言うことには意味上の問題があると思いますx == y。例えば：

// C++
double inf = std::numeric_limits<double>::infinity();
double x = 0.0 / 0.0;
double y = inf - inf;

にx等しいと見なす意味のある理由はないと私は主張しyます。それらが同等の数であるとはほとんど結論できません。それらはまったく数字ではないので、それは完全に無効な概念のように思えます。

さらに、API設計の観点からすると、多くのプログラマーが使用することを目的とした汎用ライブラリーで作業している場合、最も一般的な業界標準の浮動小数点セマンティクスを使用することは理にかなっています。優れたライブラリの目的は、ライブラリを使用する人の時間を節約することです。そのため、非標準の動作を組み込むことは混乱を招きやすいのです。

問題があります。IEEE754は、数値演算のアプリケーションに適した方法で関係演算と等価性を定義しています。ソートやハッシュにはあまり適していません。したがって、数値に基づいて配列をソートする場合、または数値をセットに追加する場合、またはディクショナリのキーとして使用する場合は、NaN値が許可されていないか、IEEE754を使用しないことを宣言します組み込み操作。ハッシュテーブルは、すべてのNaNが同じ値に一致していることを確認し、互いに等しく比較する必要があります。

Vectorを定義する場合、数値のみの目的でそれを使用するか、それともソートおよびハッシュと互換性があるべきかどうか、設計上の決定を行う必要があります。個人的には数値的な目的がもっと重要だと思います。並べ替え/ハッシュが必要な場合は、Vectorをメンバーとしてクラスを記述し、そのクラスのハッシュと等価性を好きなように定義できます。