Kayan nokta modülü kesinliği neden önemlidir?

Çoğu Smalltalk lehçesi şu anda naif bir hatalı yüzen modül (fmod / kalan) uygulamaktadır.
Bunu, Squeak / Pharo ve sonunda standartlara diğer Smalltalk bağlılığını (IEEE 754, ISO / IEC 10967) iyileştirmek için değiştirdim, çünkü diğer son teknoloji kayan nokta işlemleri için yaptığım gibi.

Bununla birlikte, bu değişikliklerin benimsenmesi için, standarda bağlı kalmanın akranlarımı ikna etmek için yeterli olmayacağını tahmin ediyorum, bu nedenle bu kesinliğin hangi durumlarda gerçekten önemli olacağını açıklamak bana çok yardımcı olacaktır. Şimdiye kadar kendime iyi bir örnek bulamadım.

Buradaki herhangi biri, bu modülün kesinliğinin neden / ne zaman / nerede (IOW hangi algoritmada) önemli olduğunu biliyor mu?

arithmetic floating-point

— aka.nice
kaynak

Ben düşünüyorum sen daha iyi cevaplar elde edebiliriz Hesaplamalı Bilim tür konular onların (alt) etki alanında daha önemli olduğu için. Her durumda, soru ontopiktir ve cevaplamadan birkaç gün önce cevap vermelisiniz.

— Raphael

Beni ürperten fmod / modf doğruluğuna dayanan bir kod gördüm, ancak bir dilin saf olmayan bir kayan nokta modülünü uygulamaya cesaret edebileceği olasılığı daha da korkutucu görünüyor. Örnek kod: (1) Kalanı alın. (2) Sıfır ise durdurun. (3) 2 ile çarpın ve (1) 'e gidin. Bu süreçte bazı yararlı çalışmalar yapılabilir, ancak asıl önemli olan, bu sürecin sona ermesi, kalanların kesinliği ve 2 ile çarpımın doğruluğuna dayanmasıdır. Burada daha eksiksiz bir cevap vermem gerekip gerekmediğinden emin değilim, çünkü Hesaplamalı Bilimler daha uygun görünüyor bu soru için.

— Thomas Klimpel

Bir tahmin: bir trigonometrik fonksiyonun girişini normalleştirmek.

— Paul A. Clayton

@ThomasKlimpel Referans bulursanız ilgileniyorum. Naive kalanın (I --E en yakın çift ops'e yuvarlandığı şekilde (x - ((y / x) kesilmiş * x)) olarak tanımlandığını, tamRem (x, y) == 0 => naiveRem (x, y) olduğunu kanıtlayabiliriz. == 0. Sorun tam tersi - yanlış tam bölme pozitif - naiveRem (4.0,0.1) == 0.0 gibi birçok durumda ne yazık ki naif beklentilere uyuyor!

— aka.nice

@ PaulA.Clayton evet, derece olarak sinüs için ... Yine de, sanırım naif rem eşit olarak iyi çalışır ve yakl. 360 derece sadece 6 bitlik bir aralığa sahip olduğundan ve 360'a bölünmesi 360'ın katlarının öncülleri için asla yuvarlanmadığı için ... radyanlar için iyi bir kütüphane birden fazla hassasiyet gerektirir, çift hassasiyetle sınırlı kesin bir rem yapar gerçekten böyle bir durumda yardım?

— aka.nice

Yanlış kayan nokta uygulamasının hava durumunu etkilediğini unutmayın.

Farklı donanımlarda aynı girdilerle hava tahminlerini çalıştıran testler yapıldı ve tahminler ayrıldı. Yinelemeli algoritmayı çalıştırıyorsanız, burada veya orada küçük bir yuvarlama farkı güneş ışığının yağmura dönüşmesine neden olabilir.

Standartlardaki yuvarlama kuralları (IEEE 754, ISO / IEC 10967) dikkatle düşünülmüştür, böylece sayısal algoritmalar en doğru şekilde öngörülebilir davranır ve her seferinde aynı sonucu üretir. Bu yuvarlama kuralları için tasarlanmış standart sayısal algoritmaları takip etmemek kırılacak ve hava durumu tahminleri gibi yinelemeli algoritmalar rastgele bir sonuç bile verebilir.

(ve bu hava tahminleri hakkında bir şey söylemiyor mu? :)

— Goswin von Brederlow
kaynak

Öte yandan, kelebek etkisi güneş ışığını yağmura değiştirirse, sonuçlarınız yine de yararlı olmadı.

— gnasher729

Bir zamanlar, kayan verileri ASCII'ye yeterli basamakla kaydettim. Bir müşteri bana bir sorun göstermek istedi, ancak ASCII dosyasındaki verileri geri yükledikten sonra sorun ortadan kalktı. Ben birkaç ulp kapalı önemli değil dedim, eğer onun sorunu şartlı, yine de yapabileceğim bir şey yok. Bunun kendi işi olduğunu, benimki de kendi sorunlarının tekrarlanabilirliğini sağlayan yazılımlar sağlayacağını söyledi. Haklıydı.

— aka.nice

Bu nedenle% a kullanarak onaltılık sayılar olarak kaydedmeler için kayan nokta sayıları çıkarmalısınız.

— Goswin von Brederlow