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" - mamy
problem "arytmetyka liczb double jest źle zaimplementowana". Miałem napisać
"ROTFL", ale jak się głębiej zastanowić - nie ma się z czego śmiać.

do góry

Użytkownik "bartekltg" <b...@g...com> napisał:

> Obcinanie pośrednich wyników do double (przy wejściu/wyjśćiu funkcji)
> kontra liczenie wszystkiego w rejestrach koprocesora, czy coś głębszego?

Napewno to + mozliwa w tym przypadku (czyli funkcji inline) optymalizacja calosciowa
wyrazenia (parse-tree, semikodu - i kodu wynikowego/maszynowego).

Poniewaz inline to tylko sugestia a nie oblig, wiec w praktyce moga (i dzieja sie)
"cuda" np. w debug sa inne wyniki fp niz w release, niektore funkcje po dodaniu
niewinnej linijki daja daja nieco inne wyniki itp itd.
W tym kontekscie "problem" buraka hrabiego (jak i on sam) z DBL_EPSILON jest
po prostu smieszny.

AK

do góry

slawek <s...@h...pl> wrote:

> Panie Adamie, zadam takie osobiste pytanie:

Nie do Ciebie piszę. Ty już pokazałeś w tym temacie swój poziom.

--
Gof
http://www.chmurka.net/

do góry

Użytkownik "slawek" <h...@s...pl> napisał w:

>>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 .

Nie buraku i (jak widac) niedouku.
Takie porownania _zawsze_ robi sie np. w ten sposob.

int fp
a > b (a - b) > EPS
a < b (a - b) > -EPS
a >= b (a - b) >= -EPS
a <= b (a - b) <= EPS
a == b fabs(a - b) <= EPS
a != b fabs(a - b) > EPS

Wszedzie. W numeryce, nawet w bankowosci (nie wszedzie jest/byl decimal)
slowem wszedzie gdzie wystepuja dzialania na fp

W dodatku to EPS winno byc o wiele wieksze od DBL_EPSILON
i innych maszynowych bebechow (czesto jest to zreszta EPS wzgledne).
Owszem, masochistow sie nie uleczy wiec mozna im zezwolic
na uzycie DBL_EPSILON jako EPS, tyle te to podwojone (2.22..) z
naglowkow C z Pythona i Matlaba. Sam sobie odpowiedz dlaczego.
Przy pojedynczym pojawiaja sie "male klopoty".

AK

do góry

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

do góry

On 06.11.2012 11:31, AK wrote:
> Poniewaz inline to tylko sugestia a nie oblig, wiec w praktyce moga (i
> dzieja sie)
> "cuda" np. w debug sa inne wyniki fp niz w release, niektore funkcje po
> dodaniu
> niewinnej linijki daja daja nieco inne wyniki itp itd.

boost::Interval Arithmetic Library - wychodzi ~2x wolniej, ale pozwala
całkiem nieźle oszacować, czy uzyskany wynik jest czymś więcej niż
nagromadzeniem błędów obliczeniowych.

--
Pozdrawiam
Michoo

do góry

Autokorekta typo:

> a < b (a - b) > -EPS

winno byc:
a < b (a - b) < -EPS

AK

do góry

W dniu wtorek, 6 listopada 2012 10:48:21 UTC użytkownik AK napisał:

> Nie buraku i (jak widac) niedouku.
>
> Takie porownania _zawsze_ robi sie np. w ten sposob.
>
>
>
> int fp
>
> a > b (a - b) > EPS
>
> a < b (a - b) > -EPS
>
> a >= b (a - b) >= -EPS
>
> a <= b (a - b) <= EPS
>
> a == b fabs(a - b) <= EPS
>
> a != b fabs(a - b) > EPS

Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:

if (a >= 0) {
b = sqrt(a);
} else {
// zglos blad ze a ujemne
}

to zastepowanie "a >= 0" przez "a >= EPS" nie ma sensu.

RW

do góry

W dniu wtorek, 6 listopada 2012 11:03:09 UTC użytkownik Michoo napisał:
> On 06.11.2012 11:31, AK wrote:
>
> > Poniewaz inline to tylko sugestia a nie oblig, wiec w praktyce moga (i
>
> > dzieja sie)
>
> > "cuda" np. w debug sa inne wyniki fp niz w release, niektore funkcje po
>
> > dodaniu
>
> > niewinnej linijki daja daja nieco inne wyniki itp itd.
>
>
>
> boost::Interval Arithmetic Library - wychodzi ~2x wolniej, ale pozwala
>
> całkiem nieźle oszacować, czy uzyskany wynik jest czymś więcej niż
>
> nagromadzeniem błędów obliczeniowych.

Da sie to "wrzucic" do starego kodu bez zmudnego przepisywania kazdej linijki?

RW

do góry

On 06.11.2012 13:31, Roman W wrote:
>
> Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:
>
> if (a>= 0) {

Ale to jest porównanie ze stałą a nie porównanie dwóch liczb.

--
Pozdrawiam
Michoo

do góry