W dniu poniedziałek, 25 marca 2013 15:12:32 UTC+1 użytkownik AK napisał:

> Np. dlatego ze porownujesz liczby zmiennoprzecinkowe
> "na ostro" a tego nie wolno robic (prawie) nigdy !
Nie chciałem powiedzieć ani że wolno, ani że nie wolno.

Chcę powiedzie tylko to, że jeśli zarówno argumenty funkcji
jak i zwracane wartości są sumą (całkowitych) potęg dwójki i
mieszczą się w zakresie liczby zmiennoprzecinkowej, to nie
ma żądnych ważnych powodów, aby procesor podał wartość
przybliżoną - wtedy może podać dokładną.

Jeśli w powyższych warunkach jedna para: kompilator, procesor
daje dokładną wartość, a druga nie daje, to chcę powiedzieć
tylko to, że ta pierwsza działa trochę dokładniej.

Niemniej temat czy wolno czy nie wolno jest ciekawy, nadawałby
się na osobny wątek. Mam taki jeden program, w którym
funkcja działa pod warunkiem że suma jej argumentów równa
się jeden. W trakcie długotrwałych obliczeń, algorytmem
ewolucyjnym przerzucam z jednego argumentu do drugiego
jakąś wartość. Np.
a = 0.75
b = 0.25
tmp = a * 0.25;
a -= tmp;
b += tmp;

Okazuje się, że często działa to zgodnie z oczekiwaniami, czyli
strata dokładności po dobie obliczeń jest w okolicach zera, albo
wręcz jest równa zero. Niestety na niektórych procesorach muszę
co ileś iteracji robić poprawkę straconej dokładności...

Niby można to wytłumaczyć tym, że na typie zmiennoprzecinkowym mamy
obliczenia przybliżone. Ale jeśli procesor/kompilator akurat dla jakiś
argumentów może dać dokładny wynik a nie daje... to ja jakoś wolę nazywać
gorszą jakością procesora czy kompilatora.

Pozdrawiam