IEEE754 NaN değerleri için yanlış dönen tüm karşılaştırmalar için gerekçe nedir?

NaN değerlerinin karşılaştırılması neden diğer değerlerden farklı davranıyor? Yani, ==, <=,> =, <,> operatörleriyle yapılan tüm karşılaştırmalar, bir veya her iki değer NaN'dir, diğer tüm değerlerin davranışının aksine yanlış döndürür.

Bunun sayısal hesaplamaları bir şekilde basitleştirdiğini düşünüyorum, ancak Kahan'ın IEEE 754'ün Durumu ile ilgili diğer tasarım kararlarını ayrıntılı olarak tartışan Ders Notlarında bile açıkça belirtilen bir neden bulamadım .

Bu sapkın davranış, basit veri işleme yaparken sorun yaratır. Örneğin, bir C programında bazı gerçek değerli alan wrt kayıt listesi sıralarken Ben maksimum öğe olarak NaN işlemek için ekstra kod yazmanız gerekir, aksi takdirde sıralama algoritması karışık olabilir.

Düzenleme: Şimdiye kadar cevapların hepsi NaNs karşılaştırmak anlamsız olduğunu savunuyor.

Kabul ediyorum, ancak bu doğru cevabın yanlış olduğu anlamına gelmez, bunun yerine Neyse ki var olmayan bir Boolean Değil (NaB) olacaktır.

Bu yüzden karşılaştırmalar için doğru veya yanlış döndürme seçimi benim görüşümde ve genel veri işleme için, olağan yasalara (== yansıma, <, ==,> trikotomi), en yeni veri yapılarına uyması avantajlı olacaktır. bu yasalara dayanan karışık olur.

Bu yüzden, sadece felsefi akıl yürütme değil, bu yasaları çiğnemenin somut bir avantajını istiyorum.

Edit 2: Sanırım neden NaN'i maksimal yapmanın kötü bir fikir olacağını anladım, üst limitlerin hesaplanmasını bozacaktı.

NaN! = NaN, örneğin bir döngüde yakınsamanın saptanmasını önlemek için arzu edilebilir.

while (x != oldX) {
    oldX = x;
    x = better_approximation(x);
}

ancak mutlak farkı küçük bir limitle karşılaştırarak daha iyi yazılmalıdır. IMHO bu NaN'de refleksiviteyi kırmak için nispeten zayıf bir argüman.

IEEE-754 komitesinin üyesiydim, işleri biraz açıklığa kavuşturmaya yardımcı olacağım.

İlk olarak, kayan nokta sayıları gerçek sayılar değildir ve kayan nokta aritmetiği gerçek aritmetiğin aksiyomlarını karşılamaz. Trikotomi, gerçek aritmetiğin yüzer için geçerli olmayan tek özelliği değil, hatta en önemlisi değildir. Örneğin:

• Toplama çağrışımsal değildir.
• Dağıtım kanunu geçerli değildir.
• Tersine çevrilmemiş kayan nokta sayıları vardır.

Devam edebilirdim. Bildiğimiz ve sevdiğimiz gerçek aritmetiğin tüm özelliklerini karşılayan sabit boyutlu bir aritmetik türü belirtmek mümkün değildir . 754 komitesi bazılarını bükmeye veya kırmaya karar vermek zorundadır. Bu, bazı oldukça basit ilkeler tarafından yönlendirilmektedir:

1. Mümkün olduğunda, gerçek aritmetik davranışını eşleştiriyoruz.
2. Yapamadığımızda, ihlalleri mümkün olduğunca öngörülebilir ve teşhis edilmesi kolay hale getirmeye çalışıyoruz.

"Bu doğru cevabın yanlış olduğu anlamına gelmez" yorumuna gelince, bu yanlıştır. Yüklem daha küçük (y < x)olup olmadığını sorar . Eğer NaN ise, o zaman olduğu değil herhangi kayan nokta değerinden düşük cevap mutlaka yanlıştır yüzden.yxyx

Trikotominin kayan nokta değerleri için geçerli olmadığını belirttim. Ancak, benzer bir özellik var. 754-2008 standardının 5.11, 2. paragrafı:

Dört birbirini dışlayan ilişki mümkündür: küçük, eşit, büyük ve düzensiz. Son durum, en az bir işlenen NaN olduğunda ortaya çıkar. Her NaN sıralamasız olarak kendisi de dahil olmak üzere her şeyi karşılaştırır.

NaN'leri işlemek için ekstra kod yazarken, kodunuzu NaN'lerin düzgün bir şekilde düşeceği şekilde yapılandırmak genellikle (her zaman kolay olmasa da) mümkündür, ancak bu her zaman böyle değildir. Değilse, bazı ekstra kodlar gerekli olabilir, ancak bu, cebirsel kapanışın kayan nokta aritmetiğine getirdiği rahatlığı ödemek için küçük bir fiyattır.

Zeyilname: Birçok yorumcu, NaN! = NaN'ı benimsemenin, bilinen herhangi bir aksiyomu korumadığı görülmediği gerekçesiyle, eşitlik ve trikotominin refleksivitesini korumanın daha yararlı olacağını savunmuştur. Bu bakış açısına sempati duyduğumu itiraf ediyorum, bu yüzden bu cevabı tekrar gözden geçirip biraz daha fazla bağlam sunacağımı düşündüm.

Kahan'la konuşmamdaki anlayışım NaN! = NaN'nin iki pragmatik düşünceden kaynaklandığı yönündedir:

• Bu mümkün olduğunda x == yeşdeğer olmalıdır x - y == 0(gerçek aritmetik teoremi olmanın ötesinde, bu, donanımın uygulanmasını daha fazla yer verimli hale getirir, bu da standardın geliştirildiği zaman çok önemlidir - ancak bunun x için ihlal edildiğine dikkat edin. = y = sonsuzluk, bu yüzden tek başına büyük bir neden değil; makul bir şekilde bükülmüş olabilir (x - y == 0) or (x and y are both NaN)).

• Daha da önemlisi, isnan( )NaN'nin 8087 aritmetiğinde resmileştirildiği sırada hiçbir belirti yoktu ; programcılara, programlama dillerine bağlı olmayan ve isnan( )uzun yıllar alabilecek bir şey sağlayan NaN değerlerini tespit etmek için uygun ve etkili bir yol sağlamak gerekiyordu. Kahan'ın konuyla ilgili kendi yazılarını alıntılayacağım:

NaN'lerden kurtulmanın bir yolu olmasaydı, bunlar CRAY'lardaki belirsizlikler kadar işe yaramazdı; karşılaşır karşılaşmaz, belirsiz bir sonuca belirsiz bir süre devam etmek yerine hesaplama en iyi şekilde durdurulacaktır. Bu yüzden NaN'ler üzerindeki bazı operasyonlar NaN dışı sonuçlar vermelidir. Hangi operasyonlar? … İstisnalar, C, "x == x" ve "x! = X" tahminlerini içerir; bunlar, her sonsuz veya sonlu x sayısı için sırasıyla 1 ve 0'dır, ancak x, bir Sayı Değil (NaN) ise tersidir; bunlar, NaN'ler ve NaN için bir kelime içermeyen dillerdeki bir sayılar ve isNaN (x) arasındaki tek basit istisnai ayrımı sağlar.

Bunun aynı zamanda “A-Boolean Değil” gibi bir şeyi döndürmeyi engelleyen mantık olduğunu da unutmayın. Belki de bu pragmatizm yanlış yerleştirilmişti ve standardın zorunlu olması gerekirdi isnan( ), ancak bu, dünya dilinin benimsenmesini programlamayı beklerken, NaN'yi birkaç yıl boyunca verimli ve rahat bir şekilde kullanmak neredeyse imkansız olurdu. Bunun makul bir ödünleşme olacağına ikna olmadım.

Açık konuşmak gerekirse: NaN == NaN sonucu artık değişmeyecek. Onunla yaşamayı öğrenmek internette şikayet etmekten daha iyidir. Kaplar için uygun bir sipariş ilişkisinin de olması gerektiğini iddia etmek isterseniz , favori programlama dilinizin totalOrderIEEE-754 (2008) 'de standartlaştırılmış yüklemi uygulamasını tavsiye etmenizi öneririm . Şu anda Kahan'ın mevcut durumu motive eden endişesinin geçerliliğinden bahsetmemiş olması.

NaN tanımlanmamış bir durum / sayı olarak düşünülebilir. 0/0 kavramının undefined veya sqrt (-3) kavramına benzer (kayan noktanın yaşadığı gerçek sayı sisteminde).

NaN, bu tanımlanmamış durum için bir tür yer tutucu olarak kullanılır. Matematiksel olarak, undefined, undefined ile eşit değildir. Tanımlanmamış bir değerin başka bir tanımlanmamış değerden daha büyük veya daha küçük olduğunu da söyleyemezsiniz. Bu nedenle, tüm karşılaştırmalar yanlış döndürür.

Bu davranış, sqrt (-3) ile sqrt (-2) arasında karşılaştığınız durumlarda da avantajlıdır. Her ikisi de NaN döndürürler, ancak aynı değeri döndürmelerine rağmen eşdeğer değildirler. Bu nedenle, NaN ile uğraşırken eşitlik her zaman yanlış dönen arzu edilen davranıştır.

Başka bir benzetme yapmak için. Size iki kutu teslim edersem ve hiçbirinin elma içermediğini söylesem, kutuların aynı şeyi içerdiğini söyler misiniz?

NaN, bir şeyin ne olduğu hakkında değil, sadece ne olduğu hakkında hiçbir bilgi içermez. Dolayısıyla bu unsurların kesinlikle eşit olduğu söylenemez.

NaN hakkındaki wikipedia makalesinde , aşağıdaki uygulamalar NaN'lere neden olabilir:

• Tüm matematiksel işlemler> en az bir işlenen olarak NaN ile
• 0/0, ∞ / ∞, ∞ / -∞, -∞ / ∞ ve -∞ / -∞ bölümleri
• 0 × ∞ ve 0 × -∞ çarpımları
• ∞ + (-∞), (-∞) + ∞ ilaveleri ve eşdeğer çıkarma.
• Negatif bir sayının kare kökünü almak, negatif bir sayının logaritmasını almak, 90 dereceden (veya π / 2 radyan) tek bir katının teğetini almak veya ters sinüsü almak da dahil olmak üzere, alanın dışındaki argümanlara bir işlev uygulamak veya -1'den küçük veya +1'den büyük bir sayının kosinüsü.

Bu operasyonlardan hangisinin NaN'yi yarattığını bilmenin bir yolu olmadığından, bunları karşılaştırmanın mantıklı bir yolu yoktur.

Tasarım gerekliliğini bilmiyorum, ama burada IEEE 754-1985 standardından bir alıntı:

"İşlenen biçimleri farklı olsa bile kayan nokta sayılarını desteklenen tüm biçimlerde karşılaştırmak mümkün olacaktır. Karşılaştırmalar tamdır ve asla taşmaz veya taşmaz. Karşılıklı olarak dört dört ilişki mümkündür: daha küçük, eşit, daha büyük ve sırasız Son durum, en az bir işlenen NaN olduğunda ortaya çıkar. Her NaN, kendisi de dahil olmak üzere her şeyi sırasız olarak karşılaştırır. "

Sadece tuhaf görünüyor çünkü NaN'lere izin veren çoğu programlama ortamı da 3 değerli mantığa izin vermiyor. Karışıma 3 değerli mantık atarsanız, tutarlı olur:

• (2.7 == 2.7) = doğru
• (2.7 == 2.6) = yanlış
• (2.7 == NaN) = bilinmiyor
• (NaN == NaN) = bilinmiyor

.NET bile bir bool? operator==(double v1, double v2)işleç sağlamaz , bu yüzden aptalca (NaN == NaN) = falsesonuçla sıkışıp kalırsınız .

NaN (Bir Sayı Değil) tam olarak şu anlama gelir: Bu bir sayı değil ve bu yüzden karşılaştırmak gerçekten mantıklı değil.

nullİşlenenlerle SQL'de aritmetik gibi biraz : Hepsi sonuçlanır null.

Kayan nokta sayıları için yapılan karşılaştırmalar sayısal değerleri karşılaştırır. Bu nedenle, sayısal olmayan değerler için kullanılamazlar. NaN bu nedenle sayısal anlamda karşılaştırılamaz.

Aşırı basitleştirilmiş cevap, bir NaN'nin sayısal bir değere sahip olmamasıdır, bu nedenle içinde başka bir şeyle karşılaştırılacak hiçbir şey yoktur.

+ INF gibi davranmalarını istiyorsanız, NaN'lerinizi test etmeyi ve yerine + INF eklemeyi düşünebilirsiniz.

NaN'ın herhangi bir gerçek sayı ile karşılaştırılmasının uyumsuz olması gerektiğine katılırken, NaN'nin kendisiyle karşılaştırılmasının sadece bir nedeni olduğunu düşünüyorum. Örneğin, NaN sinyalleri ile sessiz NaN sinyalleri arasındaki fark nasıl keşfedilir? Sinyalleri bir Boole değerleri kümesi (yani bir bit-vektör) olarak düşünürsek, bit-vektörlerinin aynı mı yoksa farklı mı olduğunu sorabilir ve kümeleri buna göre sıralayabilir. Örneğin, maksimum önyargılı bir üs kodunun çözülmesinde, anlamlılık, anlamlılığın en önemli bitini ikili formatın en önemli bitine hizalanacak şekilde kaydırılırsa, negatif bir değer sessiz bir NaN olur ve herhangi bir pozitif değer sinyal NaN olmak. Sıfır elbette sonsuzluğa ayrılmıştır ve karşılaştırma düzensiz olacaktır. MSB hizalaması, farklı ikili formatlardan bile sinyallerin doğrudan karşılaştırılmasına izin verecektir. Aynı sinyal kümesine sahip iki NaN eşdeğerdir ve eşitliğe anlam verir.

Benim için bunu açıklamanın en kolay yolu:

Bir şeyim var ve elma değilse o zaman portakal mı?

NaN'yi başka bir şeyle (kendisinin bile) karşılaştıramazsınız çünkü değeri yoktur. Ayrıca herhangi bir değer olabilir (bir sayı hariç).

Bir şey var ve bir sayıya eşit değilse o zaman bir dize mi?

Çünkü matematik, sayıların "sadece var olduğu" alandır. Bilgisayar size gerekir başlatmak bu sayıları ve tutmak sizin ihtiyaçlarına göre devlet. O eski günlerde bellek başlatma asla güvenemeyeceğiniz şekillerde çalıştı. "Ah, 0xCD ile her zaman başlatılacak, algo'm kırılmayacak" diye düşünmenize asla izin veremezdiniz .

Bu nedenle , algoritmanızın emilmesine ve kırılmasına izin vermeyecek kadar yapışkan olan uygun karıştırmayan çözücüye ihtiyacınız vardır . Sayıları içeren iyi algoritmalar çoğunlukla ilişkilerle çalışacak ve () ilişkileri atlanacak olanlar.

Bu, bilgisayar belleğinden rastgele cehennemi programlamak yerine, yeni değişkene yaratabileceğiniz yağdır. Ve algoritmanız her ne ise, kırılmaz.

Daha sonra, aniden algoritmanızın NaN ürettiğini öğrendiğinizde, her şubeye birer birer bakarak temizlemek mümkündür. Yine, "her zaman yanlış" kural bu konuda çok yardımcı oluyor.

Çok kısa cevap:

Çünkü aşağıdakiler: nan / nan = 1 TUTMAMALIDIR. Aksi takdirde inf/inf1 olur.

(Bu nedenle naneşit olamaz nan. Arşimet mülkünü tatmin eden bir sette herhangi bir emir ilişkisine saygı duyulursa >veya kabul <edilirse nan, yine nan / nan = 1sınırda oluruz ).