`Vektör <float> .Equals` dönüşlü olmalı mı yoksa IEEE 754 anlambilimine uygun mu?

Eşitlik için kayan nokta değerleri karşılaştırılırken iki farklı yaklaşım vardır:

• NaNIEEE 754 şartnamesine uyan kendine eşit olmamalıdır .
• NaNEşdeğerlik ilişkisinin tanımlanması için gerekli olan refleksivitenin matematiksel özelliğini sağlayan kendisine eşit olmak

C # ( floatve double) içindeki yerleşik IEEE kayan nokta türleri ve ==ve !=(ve ilişkisel operatörler gibi <) için IEEE semantiğini takip eder, ancak object.Equals, IEquatable<T>.Equals(ve CompareTo) için yansıma sağlar .

Şimdi float/ üstünde vektör yapılar sağlayan bir kütüphane düşünün double. Böyle bir vektör tipi aşırı yüklenir ==/ !=ve geçersiz kılınır object.Equals/ IEquatable<T>.Equals.

Herkesin kabul ettiği şey, IEEE anlambilimine uymak ==/ !=uymaktır. Soru, böyle bir kütüphanenin Equalsyöntemi (eşitlik operatörlerinden ayrı olarak) refleksif veya IEEE anlambilimine uygun bir şekilde uygulamasıdır.

IEEE semantiğini aşağıdakiler için kullanmak için bağımsız değişkenler Equals:

• IEEE 754'ü takip ediyor

• SIMD talimatlarından yararlanabileceğinden (muhtemelen çok daha hızlı)

  Stackoverflow hakkında, SIMD talimatlarını ve performans etkilerini kullanarak refleksif eşitliği nasıl ifade edeceğiniz hakkında ayrı bir soru sordum: Kayan nokta eşitliği karşılaştırması için SIMD talimatları

  Güncelleme: Üç SIMD talimatını kullanarak refleksif eşitliği etkili bir şekilde uygulamak mümkün görünmektedir.

• İçin dokümantasyon Equals, kayan noktayı dahil ederken refleksivite gerektirmez:

  Aşağıdaki ifadeler, Equals (Object) yönteminin tüm uygulamaları için doğru olmalıdır. Listede, x, yve zboş olmayan nesne referanslarını temsil eder.

  x.Equals(x)truekayan noktalı türleri içeren durumlar dışında döner . Bkz. ISO / IEC / IEEE 60559: 2011, Bilgi teknolojisi - Mikroişlemci Sistemleri - Kayan Nokta aritmetiği.

• Sözlük anahtarı olarak şamandıralar kullanıyorsanız, günah durumunda yaşıyorsunuz ve aklı başında davranış beklememelisiniz.

Dönüşlü olma argümanları:

• Bu da dahil olmak üzere, mevcut tipleri, uyuyor Single, Double, Tupleve System.Numerics.Complex.

  BCL'de Equalsrefleksif olmak yerine IEEE'yi takip eden herhangi bir örnek bilmiyorum . Sayaç örnekler Single, Double, Tupleve System.Numerics.Complex.

• Equalsçoğunlukla refleksiviteye dayanan kapsayıcılar ve arama algoritmaları tarafından kullanılır. Bu algoritmalar için, bir performans kazancı, çalışmalarını önlüyorsa önemsizdir. Performans için doğruluktan ödün vermeyin.
• Tüm karma tabanlı setleri ve sözlükleri kırar, Contains, Find, IndexOfçeşitli koleksiyonlardan / LINQ set bazlı LINQ operasyonları (üzerinde Union, Exceptvs.) veri içeriyorsa NaNdeğerlerini.

• IEEE semantiğinin kabul edilebilir olduğu gerçek hesaplamaları yapan kod genellikle somut türler üzerinde çalışır ve ==/ !=(veya daha olası epsilon karşılaştırmaları) kullanır.

  Bunun için aritmetik işlemlere ihtiyaç duyduğunuzdan, şu anda jenerikler kullanarak yüksek performanslı hesaplamalar yazamazsınız, ancak bunlar arayüzler / sanal yöntemler aracılığıyla kullanılamaz.

  Bu nedenle, daha yavaş bir Equalsyöntem çoğu yüksek performans kodunu etkilemez.

• IEEE semantiğine veya performans avantajına ihtiyaç duyduğunuz durumlarda bir IeeeEqualsyöntem veya bir sağlamak mümkündür IeeeEqualityComparer<T>.

Kanımca bu argümanlar dönüşlü bir uygulamayı kuvvetle desteklemektedir.

Microsoft'un CoreFX ekibi böyle bir vektör türünü .NET'e tanıtmayı planlıyor. Benden farklı olarak , temel olarak performans avantajları nedeniyle IEEE çözümünü tercih ediyorlar . Son bir sürümden sonra böyle bir karar kesinlikle değiştirilmeyeceğinden, büyük bir hata olduğuna inandığım şeyden topluluktan geri bildirim almak istiyorum.

IEEE davranışının doğru olduğunu iddia ediyorum. NaNs hiçbir şekilde birbirine eşdeğer değildir; sayısal bir cevabın uygun olmadığı kötü tanımlanmış koşullara karşılık gelirler.

Çoğu işlemcinin doğal olarak desteklediği IEEE aritmetiği kullanmanın getirdiği performans avantajlarının ötesinde, eğer varsa isnan(x) && isnan(y), o zaman semantik bir sorun olduğunu düşünüyorum x == y. Örneğin:

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

Birisinin xeşit olarak düşünmesinin anlamlı bir nedeni olmadığını iddia ediyorum y. Eşdeğer sayılar olduğu sonucuna varamazsınız; bunlar sayı değil, bu yüzden tamamen geçersiz bir kavram gibi görünüyor.

Ayrıca, bir API tasarım perspektifinden bakıldığında, birçok programcı tarafından kullanılması amaçlanan genel amaçlı bir kitaplık üzerinde çalışıyorsanız, en endüstriye özgü kayan nokta semantiğini kullanmak mantıklıdır. İyi bir kütüphanenin amacı, onu kullananlar için zamandan tasarruf etmektir, bu nedenle standart dışı davranışlarda bina kafa karışıklığı için olgunlaşır.

Bir sorun var: IEEE754 ilişkisel işlemleri ve eşitliği sayısal uygulamalara uygun şekilde tanımlar. Sıralama ve hashlama için uygun değildir. Bir diziyi sayısal değerlere göre sıralamak istiyorsanız veya bir kümeye sayısal değerler eklemek veya bunları sözlükte anahtar olarak kullanmak istiyorsanız, NaN değerlerine izin verilmediğini bildirirsiniz veya IEEE754 kullanmazsınız yerleşik işlemler. Karma tablonuz tüm NaN'lerin aynı değerle eşleştiğinden emin olmalı ve birbirleriyle eşit olmalıdır.

Vector öğesini tanımlarsanız, yalnızca sayısal amaçlar için kullanmak isteyip istemediğinize veya sıralama ve karma ile uyumlu olup olmayacağına dair tasarım kararı vermeniz gerekir. Şahsen sayısal amacın çok daha önemli olması gerektiğini düşünüyorum. Sıralama / karma işlemi gerekiyorsa, Vector ile bir sınıfı üye olarak yazabilir ve karma ve eşitliği o sınıfta istediğiniz gibi tanımlayabilirsiniz.