🚀 go-pugleaf

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
>> Czyli jak porownujemy liczby FP? Ano zawsze tak:
>> a == b    =>   abs(a - b) <= EPS
>
> Poczytaj sobie PEP485.

Znam go w miare dokladnie.
Mowilem zreszta wyraznie, ze najczesciej stosuje sie EPS wzglednie,
ale.. nie zawsze na to sens. Czasem/czesto to wlasnie EPS bezwzgledny
jest odpowiedniejszy. Czesto stosuje sie techniki no..nazwe je "dynamicznym EPSem"
zwlaszac w przypadku algorytmow slabo/zbieznych/malo odpornych na bledy zaikraglen/malo stabilnych
gdzie nawet stosuje sie dosc zaawansowane statystyczne szacoiwanie bledu, aby
zdecydowac czy "toto jest rowne 0.0" (np. odleglosc od ekstremum).
Czesto jest to problem sam w sobie, bo np w przypadku dochodzenia
do ekstremum badac czy na tyle malo zmienia sie krok czy wartosc fukcji
czy moze obie? A co gdy funkcja jest bardzo plaska i krok (x) zmienia sie
"kilka rzedow" bardziej od wartosci(y)? Wtedy "moze" lepiej miec/stosowac
dwa EPS(XY), co jesy funkcja jest bardzo stroma, a co jestli jest
rozna w roznym zakresie/dziedzinie? Itp itd. Problem z fp (i w ogole
z szacowaniem "czy cus jest 0.0:) wydaje sie prosty, ale nim nie jest.

> To co proponujesz nie nadaje się do danych które są z natury rzeczy mniejsze niż EPS.

.. bo przeciez EPS jest _wlasnie po to _ aby do dobrac _wlasciwie_ do skali danych
/domeny wiec: albo stosowac roznice wzgledne albo stosowac EOS _odpowiednio_
dobrany, ale bezwzgledny. Nie zawsze roznice wzgkedne maja sens. Czesto wlasnie
EPS i roznice bezwzgledne sa wlasciwe,

PS: W "moich czasach" EPS zwykle wystepowal jako parametr stosowanej
procedury/algorytmu i.. nie posiadal anu wartosc domyslnych ani zalecanych.
Pozostawiano to (i slusznie) programiscie numerykowi.

> Poprawniej jest porównywać abs(a-b) <= EPS*(abs(a)+abs(b)), ale i ten sposób - używany m.i. w 
> Numerical Recipes - ma swoje wady.

To prawda. niekiedy "zwykly"surowy bezwzgledny EPS jest odpowiedniejszy
a niekiedy (tak jak zaznaczylem) EPS jest "dynamiczny" i jest to skomplikowany
test/algorytm np. statystyczny na podstawie/bazie dotychczasowych danych.

> Bo zasadniczy problem to nie porównywanie... do tego zawsze wystarczyłoby a == b... ale 
> oszacowanie jak duże mogą być błędy zaokrągleń.

Porownananie "sztywne"wiedzac, ze sa bledy zaokraglen/kunulacja bledow itp
jest zwykla bzdura, bo zaklamuije rzeczywistosc.

>A tego nie da się wiedzieć w bibliotece numerycznej nie  znając domeny problemu.

Tak. Tu 100% zgoda.

> W szczególności są takie dane, gdzie jest  około 20 dokładnych cyfr po przecinku.

Ilosc miejsc znaczacyh mantysy tak naprawde nie ma tu znaczenia.
Problem porownania/szacowania fp bedzie taki sam nawet przy 1000 cyfr znaczacych.

Liczy sie tez dokladnosc dzialan posrednich (a moze byc rozna/mniejsza od
wyniku/formatu koncowego. Liczy sie dlugosc akumulatorow wewnetrznych
w koprocesorze itp. Bardzo madrze u Laheya napisali, ze nawet jesli na dwoch
roznych srodowiskach stosuje sie "zewnetrznie" ten sam format IEEE to i tak
wyniki (i ich bledy) moga byc inne. Wlasnie z w/w powodow.

PS: Najlepiej przyjac zasade: _nic nie wiemy o formacie/dokladnosci liczb fp_
(nawet jesli wiemy wszystko:)

AK