Użytkownik "kenobi" napisał w wiadomości grup
dyskusyjnych:f1c06cb8-0345-44a8-8207-a4773d21ebf8@go
oglegroups.com...

>pozatym jednak niechybnie masz racje
>jesli okazuje sie ze ten 2.2 nie jest
>najmniejsza liczba, tylko 1.1 tez dziala;

No właśnie rzecz w tym, że mam-i-nie-mam. Spróbuję uporządkować, ale
potrzebna mi jest definicja op(a,b). Funkcję op(a,b) definiuję jako wynik
"dodawania" wykonywanej na danym komputerze. W ten sposób nie musi być nawet
op(2,2) == 4, bo op(a,b) nie jest sumą liczb a+b w sensie matematycznym.

I teraz mamy 3 "epsilony":

1. Liczbę x, która jest najmniejszą liczbą spełniającą nierówność op( 1.0,
x ) > 1.0 .
2. Liczbę y, która jest największą liczba spełniającą równanie op( 1.0, y )
== 1.0 .
3. Liczbę z, która wynosi z = q - 1.0, gdzie q jest najmniejszą liczbą
zapisywalną w określony sposób i spełniającą warunek q > 1.0 .

Uwaga: odejmowanie w pkt. 3. należy rozumieć abstrakcyjnie, czyli ściśle
matematycznie.

Liczby x oraz y są różne na n-tym miejscu po przecinku i dlatego traktuję
je - choć niesłusznie - jako ten sam epsilon. Gdyby zwiększać ilość bitów
mantysy do nieskończoności, to granicznie stałyby się identyczne (i równe
zeru).

Liczba z jest, w bardzo dobrym przybliżeniu, 2 razy większa niż z. I tę
właśnie liczbę Bartek nazywa epsilonem. Ok, też można. Choć jest to jednak
inna definicja niż np. w Numerical Recipes, czyli dość popularnym
podręczniku nt. metod numerycznych (takim sobie, ale znacznie lepszym niż
np. podręcznik Jankowskich) i niż "miał na myśli artysta" uwieczniający się
komentarzem we float.h.

Fakt, że z jest około dwukrotnie większy niż x jest trudno wytłumaczalny
bez - czego właśnie Bartek nie potrafił wyjaśnić - wiedzy o tym, że
obliczenia FPU są robione na 80 bitowych a nie 64 bitowych liczbach float
point. Tzn. normalne liczby double mają mantysę 53 bitową, ale wewnętrznie
FPU (zmutowany Intel 80287) liczy z mantysą 63 bitową. Zaokrąglanie op(1,x)
następuje "do najbliższej", więc w ten sposób w jako wynik osiągana jest
liczba q > 1.0 - "brakującą połówkę z" dostajemy w trakcie konwersji z
mantysy 63 bitowej na 53 bitową.

Przy "różnych opcjach kompilatora(ów)" da się wymusić czasem jakieś double
double, quarduple czy extended - oraz rygorystyczne obcinanie dokładności
FPU do 53 bitów. Istnieją też prawdziwe procesory 128 bitowe i takie tam.
Więc rzeczywiście nie jest bezpiecznie polegać na wstępnie ustalonym
DBL_EPSILON - a zwłaszcza (co już pisałem) brać dosłownie wszystkich cyferek
jakie tam we float.h są wypisane.

W Wikipedii jest jak wół epsilon 1.11E-16 (dla double), ale na tej samej
stronie WWW jest przykład w Phytonie z wynikiem 2.22E-16. Już samo to
wymagałoby sprostowania, przecież Wikipedia nie jest czymś czego nie można
poprawiać - zwłaszcza jeżeli się aspiruje do bycia - jak Bartek - ekspertem
w dziedzinie.