Użytkownik "Jacek Czerwinski" napisał w wiadomości grup
dyskusyjnych:itj2s7$76f$...@n...onet.pl...

>jedno słowo na rodowód nauk poznawczych (fizyki) drugie kierunku
>praktycznego (techniki).

"Błąd pomiarowy" musiał być jakoś pojmowany od czasów najdawniejszych - i to
właśnie z przyczyn "technicznych". Dojrzałą teorię zapodał niejaki Gauss, bo
chciał zmierzyć krzywiznę przestrzeni (tj. zmierzyć czy suma kątów w
trójkącie to 180 stopni) metodami ówczesnej geodezji... i wychodziło mu
jakoś "dziwnie".

>Są to oddzielne byty, masz rację, natomiast ich dalsze skutki już nie
>różnią się zbytnio. Nie ma dużego znaczenia czy pomiar ma dokładność

Różnią się drastycznie. Mniej więcej tak, jak zegarek który "się spieszy"
(tj. skok wskazówki o działkę sekundową następuje w nim co pół sekundy), a
zegarek który ma wskazówki nieprzymocowane do osi (czyli pokazują one
zupełnie dowolne rzeczy, po prostu kręcą się niezależnie od mechanizmu
zegara).

To co teraz robi się "w obliczeniach zmiennoprzecinkowych" to zakładanie, że
owszem, prawda, wskazówki są "nieco" luźno, ale być może jednak mechanizm
nimi kręci.

Drastycznie? A jak można, inaczej niż na kredyt zaufania, wierzyć że
obliczenia na float pointsach są ok, jeżeli nie ma się oszacowania
dokładności, tj. ustalenia jak wielkie są błędy zaokrągleń? Zwróć uwagę, że
żaden FPU/CPU nie ma hardware'owo wspieranego liczenia dokładności wyniku.

Wyjaśnię to na przykładzie - mnożymy 198 razy 51 "ręcznie z oceną
dokładności"

198 to niemal 200
51 to prawie 50
ich iloczyn to 10000

Do tego miejsca mamy obliczenia a'la FPU. Rzecz w tym, że powinno się
jeszcze zrobić coś takiego

zaokrąglając 198 do 200 popełnia się błąd równy 2 czyli mniejszy niż 1%
zaokrąglając 51 do 50 popełnia się błąd równy 1 czyli mniejszy niż 2%
w przypadku iloczynu dobre oszacowanie błędu daje suma "procentów"
czyli błąd wyniku oszacowujemy na 3% (względny)
to daje błąd mniejszy niż 300 (bezwzględny)

Oczywiście, w przypadku obliczeń FPU/CPU mamy teraz (przez monokulturę
Intela - AMD i inni po prostu mają "takie same", nawet jeżeli ARM itd.) w
porywach 80 bitów binarnej mantysy (liczby long double w niektórych
systemach) - chyba że liczymy na jakiś paskudkach poósmej precyzji (nie
wspieranej przez hardware). Niemniej jednak - idea jest taka sama.

Jest rzeczą zdumiewającą, że np. właśnie Intel robi najrozmaitsze bajery -
ale nie potrafi jakoś (a może po prostu nie ujawnia?) procesorów
numerycznych liczących np. z 160 bitową mantysą.

Przy obecnej jest około 16 cyfr dziesiętnych (plus trochę jeszcze jak zmusi
się FPU do poświęcenia cechy na rzecz mantysy). To oznacza, że miliard
kroków, każdy wrzucający "epsilon" przesunie nam wynik o być może 9 cyfr.
Zostanie nam 7 cyfr znaczących. Jak jeszcze zaczniemy to odejmować od
podobnie otrzymanych wyników... oj, to nic nam nie zostanie. Przy 32 cyfrach
znaczących te miliard kroków zostawi nadal ponad 20 cyfr po przecinku. To
dalej niczego nie gwarantuje. Ale jest już trochę lepiej.

Jeżeli ktoś myśli, że wystarczą jedynie dobrze uwarunkowane algorytmy, to
niech liczy na short float. Też można.

slawek


slawek


--- Posted via news://freenews.netfront.net/ - Complaints to n...@n...net ---