Haruskah `Vector <float> .Equals` bersifat refleksif atau haruskah mengikuti semantik IEEE 754?

Saat membandingkan nilai floating point untuk kesetaraan, ada dua pendekatan berbeda:

• NaNtidak sama dengan dirinya sendiri, yang cocok dengan spesifikasi IEEE 754 .
• NaNmenjadi sama dengan dirinya sendiri, yang menyediakan properti matematika dari Refleksivitas yang penting untuk definisi relasi Kesetaraan

Tipe floating point IEEE bawaan di C # ( floatdan double) mengikuti semantik IEEE untuk ==dan !=(dan operator relasional suka <) tetapi memastikan refleksivitas untuk object.Equals, IEquatable<T>.Equals(dan CompareTo).

Sekarang pertimbangkan perpustakaan yang menyediakan struct vektor di atas float/ double. Jenis vektor seperti itu akan membebani ==/ !=dan menimpa object.Equals/ IEquatable<T>.Equals.

Apa yang semua orang setuju pada adalah bahwa ==/ !=harus mengikuti IEEE semantik. Pertanyaannya adalah, haruskah perpustakaan seperti itu menerapkan Equalsmetode (yang terpisah dari operator kesetaraan) dengan cara yang refleksif atau dengan cara yang cocok dengan semantik IEEE.

Argumen untuk menggunakan semantik IEEE untuk Equals:

• Ini mengikuti IEEE 754

• Ini (mungkin jauh lebih cepat) karena dapat memanfaatkan instruksi SIMD

  Saya telah mengajukan pertanyaan terpisah tentang stackoverflow tentang bagaimana Anda akan mengekspresikan kesetaraan refleksif menggunakan instruksi SIMD dan dampak kinerjanya: Instruksi SIMD untuk perbandingan kesetaraan floating point

  Pembaruan: Sepertinya mungkin untuk menerapkan kesetaraan refleksif secara efisien menggunakan tiga instruksi SIMD.

• Dokumentasi untuk Equalstidak memerlukan refleksivitas ketika melibatkan floating point:

  Pernyataan berikut harus benar untuk semua implementasi metode Persamaan (Objek). Dalam daftar, x, y, dan zmewakili referensi objek yang tidak nol.

  x.Equals(x)kembali true, kecuali dalam kasus yang melibatkan tipe floating-point. Lihat ISO / IEC / IEEE 60559: 2011, Teknologi informasi - Sistem Mikroprosesor - Aritmatika Titik Apung.

• Jika Anda menggunakan pelampung sebagai kunci kamus, Anda hidup dalam keadaan berdosa dan seharusnya tidak mengharapkan perilaku waras.

Argumen untuk bersikap refleksif:

• Ini konsisten dengan jenis yang ada, termasuk Single, Double, Tupledan System.Numerics.Complex.

  Saya tidak tahu preseden apa pun di BCL tempat Equalsmengikuti IEEE bukannya refleksif. Contoh kontra termasuk Single, Double, Tupledan System.Numerics.Complex.

• Equalssebagian besar digunakan oleh wadah dan algoritma pencarian yang bergantung pada refleksivitas. Untuk algoritme ini, peningkatan kinerja tidak relevan jika mencegahnya bekerja. Jangan mengorbankan kebenaran untuk kinerja.
• Rusak semua set berdasarkan hash dan kamus, Contains, Find, IndexOfpada berbagai koleksi / LINQ, operasi ditetapkan berdasarkan LINQ ( Union, Except, dll) jika data yang berisi NaNnilai-nilai.

• Kode yang melakukan perhitungan aktual di mana semantik IEEE dapat diterima biasanya bekerja pada tipe dan penggunaan konkret ==/ !=(atau lebih mungkin perbandingan epsilon).

  Saat ini Anda tidak dapat menulis perhitungan kinerja tinggi menggunakan generik karena Anda memerlukan operasi aritmatika untuk itu, tetapi ini tidak tersedia melalui antarmuka / metode virtual.

  Jadi Equalsmetode yang lebih lambat tidak akan memengaruhi kode kinerja paling tinggi.

• Dimungkinkan untuk memberikan IeeeEqualsmetode atau IeeeEqualityComparer<T>untuk kasus di mana Anda membutuhkan semantik IEEE atau Anda perlu untuk keuntungan kinerja.

Menurut pendapat saya argumen ini sangat mendukung implementasi refleksif.

Tim CoreFX Microsoft berencana untuk memperkenalkan tipe vektor seperti itu dalam .NET. Tidak seperti saya, mereka lebih suka solusi IEEE , terutama karena keunggulan kinerja. Karena keputusan seperti itu tentu tidak akan berubah setelah rilis final, saya ingin mendapatkan umpan balik dari masyarakat, tentang apa yang saya yakini sebagai kesalahan besar.

Saya berpendapat bahwa perilaku IEEE benar. NaNs tidak setara satu sama lain dengan cara apa pun; mereka sesuai dengan kondisi yang tidak jelas di mana jawaban numerik tidak sesuai.

Di luar manfaat kinerja yang berasal dari penggunaan aritmatika IEEE yang didukung sebagian besar prosesor secara bawaan, saya pikir ada masalah semantik dengan mengatakan bahwa jika isnan(x) && isnan(y), maka x == y. Contohnya:

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

Saya berpendapat bahwa tidak ada alasan yang berarti mengapa seseorang dianggap xsetara y. Anda hampir tidak dapat menyimpulkan bahwa mereka adalah angka yang setara; mereka sama sekali bukan angka, jadi sepertinya konsep yang sama sekali tidak valid.

Selain itu, dari perspektif desain API, jika Anda bekerja pada pustaka serba guna yang dimaksudkan untuk digunakan oleh banyak pemrogram, masuk akal untuk menggunakan semantik titik-mengambang yang paling khas industri. Tujuan perpustakaan yang baik adalah untuk menghemat waktu bagi mereka yang menggunakannya, sehingga membangun perilaku yang tidak standar sudah matang untuk kebingungan.

Ada masalah: IEEE754 mendefinisikan operasi relasional dan kesetaraan dengan cara yang cocok untuk aplikasi numerik. Tidak cocok untuk menyortir dan hashing. Jadi jika Anda ingin mengurutkan array berdasarkan nilai numerik, atau jika Anda ingin menambahkan nilai numerik ke set atau menggunakannya sebagai kunci dalam kamus, Anda juga menyatakan bahwa nilai NaN tidak diperbolehkan, atau Anda tidak menggunakan IEEE754 operasi bawaan. Tabel hash Anda harus memastikan bahwa semua NaN dicocokkan dengan nilai yang sama, dan membandingkan sama satu sama lain.

Jika Anda mendefinisikan Vector maka Anda harus membuat keputusan desain apakah Anda ingin menggunakannya hanya untuk tujuan numerik atau apakah itu harus kompatibel dengan pengurutan dan hashing. Saya pribadi berpikir bahwa tujuan numerik harusnya jauh lebih penting. Jika pengurutan / hashing diperlukan maka Anda dapat menulis kelas dengan Vector sebagai anggota dan mendefinisikan hashing dan kesetaraan di kelas itu seperti yang Anda suka.