D geliştiricilerinden olan Don, digitalmars.D.announce grubunda "Phobos unit testing uncovers a CPU bug" diye bir konu açtı.

Şu programdaki assert denetimi Intel işlemcilerinde başarıyla geçiyormuş (bende öyle); AMD işlemcilerinde ise geçmiyormuş:

import std.math;

void main()
{
    assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
   == 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD (Intel'de geçer, AMD'de geçmez)
}

Çünkü yl2x(0x1.0076fc5cc7933866p+40L, LN2) işleminin sonucu şöyle çıkıyormuş:

'
Intel: 0x1.bba4a9f774f49d0ap+4L
AMD: 0x1.bba4a9f774f49d0cp+4L
'

Fark, kesirli sayı gösteriminin son bitinde olduğu için o kadar önemli değil, ama işlemciler arasındaki bir farkı ortaya koymuş oluyor. (Aslında sonuç IEEE kesirli sayı kurallarına uyacaksa, o CPU'lardan birisinin hatalı olduğunu kabul edebiliriz. Beklentiyi karşılamadığına bakılırsa, hatalı olan AMD.)

Don, D'nin aşağıdaki olanakları olmasa, CPU'larda böyle bir fark bulunduğunu ortaya çıkartmış olmayacaklarını; o farkı, bir C kütüphanesindeki dönüşüm kayıplarına yoracaklarını söylüyor:

• Birim testleri

• Code coverage (güzel Türkçesini bilen var mı?): bu, dmd'nin program satırlarının ne kadarının kullanıldığını veya test edildiğini gösteren olanağı (-cov seçeneği). Çok yararlı bir olanak, çünkü örneğin birim testleri yetersiz olduğunda, bir 'if' koşulunun 'else' bloğu hiç denenmiyor olabilir. -cov, programın ne kadarının işletildiğini gösterir.

• Kesirli sayılar D'de onaltılı düzende de yazılabiliyorlar. Hatırlatmak için, şu sayfada "Kesirli sayılar" başlığında var:

  http://ddili.org/ders/d/hazir_degerler.html

Ali

Not: Bunların asıl konuyla ilgisi yok ama merakımı gidermek için yl2x'i belgelerde aradım ama bulamadım. phobos/std/math.d dosyasına baktığımda şu bildirimi görüyorum:

@safe pure nothrow real yl2x(real x, real y);         // y * log2(x)

Açıklamasından anlaşıldığına göre, birinci parametresinin 2 tabanındaki logaritmasının ikinci parametresi ile çarpımıymış.

LN2 de şöyle tanımlı:

enum real LN2 =        0x1.62e42fefa39ef358p-1; /** ln 2 */  // 0.693147 fldln2

O da 2'nin doğal logaritmasının önceden hesaplanmış olan sabit değeri.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Nasıl bir hata olduğunu anlayamadım. :huh:

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Kullanımda önemli bir hata değil; çünkü kesirli sayının en düşük biti ile ilgili.

IEEE kesirli sayı düzeni, kırpılmayı da standartlaştırmıştır. Yine günlük hayattan bir örnek: 1/3'ü virgülden sonra iki hane ile sınırlarsak, 0.33 yazarız. 2/3'ü ise 0.66 diye değil, 0.67 olarak yazarız. Çünkü öyle yazmasak, hep bir kayıp oluşur: 0.33 + 0.66 == 0.99'dur. Oysa 0.67 yazılınca, toplam 1.00 olur.

Bunu zaten hepimiz biliyoruz: kırpılan ilk hane 5 veya daha büyükse, kırpılmayan son hane bir yukarı ötelenir; 4 veya daha düşükse ötelenmez.

İşte hata, benim tahminime göre AMD'nin bu kırpılma kurallarını doğru gerçekleştirmemesinden kaynaklıyor. Tahmin...

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Teşekkürler Ali Bey.
Çok da önemli olmadığını sanıyorum ama mühendislere sıkıntı yaşatabilir.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

abi bunun basligi nerde?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Bilgisayarı bilimsel deney amaçlı kullananlara da sıkıntı yaratıyormuş. Aynı programın (D değilmiş) evdeki bilgisayarla üniversitedeki bilgisayar arasında farklı sonuç ürettiğini yazmışlar.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Mengü, sorunu doğru anladığımdan emin değilim ama asıl konu şu: :)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=19731

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]