On 06.11.2012 10:46, slawek wrote:
> Użytkownik "Tomasz Sowa" napisał w wiadomości grup
> dyskusyjnych:k79hhh$26k$...@n...dialog.net.pl...
>
>> No właśnie nie wystarczy, unie zrobiłem specjalnie żeby obliczenie
>> dodawania zrobić odpowiednio w 32 bitach (float) i 64 bitach (double). W
>> twoim przypadku obliczenia będą przeprowadzone w 80 bitach lub więcej
>> (zależnie od opcji kompilacji).
>
> Ok, ale podążając za twoim pomysłem należałoby stwierdzić, że
> jakiekolwiek porównania a > b należy usunąć z programów i zastąpić je
> porównaniami (int)a > (int)b .
>


> Czyli - zamiast problemu "DBL_EPSILON jest podany z 50% błędem"

NIE jest, nie trolluj. Już ci podawałem fragment standardu, w którym
wyraźnie stoi, że DBL_EPSILON zawiera dodatnią różnicę między 1.0 a
następną wartością reprezentowalną w typie double.


> - mamy
> problem "arytmetyka liczb double jest źle zaimplementowana".

Czy ty kiedyś siedziałeś gdzieś w pobliżu numeryki?

Jeżeli dokładność jest większa to nie jest to problem, chyba, że
programista naprawdę coś zepsuł. Precyzja w punktach wynosi 100%,
dlatego używa się ograniczeń worst-case. Nikt myślący nie zrobi w
typowym przypadku relacji równoważności[*] w oparciu o DBL_EPSILON -
zawsze to będzie jego wielokrotność.


P.S.
Skompiluj, uruchom, zrozum:

#include <cstdio>
double foo(double d){
return d;
}
main()
{
double d1=1.0;
double d2=1.5E-16;
printf("%.18lf %.18lf\n",d1+d2-1.0,foo(d1+d2)-1.0);
}

[*] Wynika to z tego, że każda operacja wprowadza przynajmniej błąd z
przedziału <0,DBL_EPSILON/2>, niektóre tak duży jak np
sqrt(DBL_EPSILON/2) - np. sqrt ;)

--
Pozdrawiam
Michoo