W dniu 2013-03-26 15:41, M.M. pisze:
> W dniu wtorek, 26 marca 2013 14:42:06 UTC+1 użytkownik darekm napisał:
>> W dniu 2013-03-26 12:25, M.M. pisze:
>>
>>> W dniu wtorek, 26 marca 2013 10:21:52 UTC+1 u�ytkownik darekm napisa�:
>>
>>>> W dniu 2013-03-25 19:36, M.M. pisze:
>>
>>>
>>
>>>> Dlaczego funkcj� pow() mia�o by liczy� r�nie dla r�nych argument�w.
>>
>>>> Oczywi�cie mo�na sobie wyobrazi� optymalizacj� (redukcj� do
mno�enia)
>>
>>>> dla wyk�adnika 2,3,4 ... ale dla wi�kszo�ci przypadk�w to b�dzie
>>
>>>> zamieniane na logarytmy (wielomiany itp) st�d problem z zaokr�gleniami.
>>
>>>
>>
>>> Niczego to nie zmienia. Logarytm tez mozna policzyc na mantysie o 2 bity
>>> dluzszej (np. na precyzji 66bitow) i wynik bylby dokladny. Jesli jakis
>>> procesor tego nie robi, to byc moze uzasadnia to moje podejrzenie, ze
>>> dziala dzieki temu troche szybciej. W koncu obliczenia na 66bitach sa
>>> wolniejsze niz na 64.
>
>> Propozycja jest nieefektywna.
> Bo to nie była propozycja.
>
>> r�wnie dobrze mo�esz sobie sam (lub u�ywana biblioteka) zaokr�gli� (albo
>> wystartowa� od 80 lub 128 bit�w) i b�dziesz mia� dok�adnie,
>> i wtedy masz wyb�r: albo szybko (64bity) albo precyzyjnie (80bit�w) albo
>> dok�adnie (80bit�w i na koniec zaokr�glone do 64)
> Czyli teraz z tego że mogę sam sobie zaokrąglić wynika, że
> 2+2=4.0001 jest bardziej dokładne niż 2+2=4 ? Jaja jakieś.
>

Przyjąłeś złą definicję dokładności.
Dokładne mogą być liczby rzeczywiste, w komputerze nie masz takich,
tylko ich zmiennoprzecinkową reprezentację obarczoną określonym błędem (
nie wspominając o ograniczonym zakresie).
Dalej przy prowadzeniu obliczeń równolegle szacujesz błąd (może się
kumulować albo znosić), im bardziej złożone obliczenia tym trudniejsze
szacowanie błędu. Zasady takie same jak np. w miernictwie.

Dalej: dokładna funkcja nie nie tylko taka, która na niektórych
argumentów podaj dokładne wyniki. Zawsze mnie śmieszy tekst księgowych:
"bilans się zupełnie nie zgadza" - bo wychodzi różnica (1000, 1 ...
0.01) Dla księgowych zaokrąglenia są abstrakcją a niedokładnośc to
"wykluczający błąd". Natomiast w obliczeniach przyrodniczych wartości
dokładne praktycznie nie występują, może tylko w zakresie obiektów
policzalnych.

Odchyłka wyniku otrzymanego od teoretycznego nie jest jedynym możliwym
błędem. Równie ważna jest ciągłość wartości funkcji. I Twoje
x=pow(2.0,2.0);
e // odpowiednio mała liczba dodatnia
y=pow(2.0,2.0+e);

i relacja pomiędzy x i y może zostać zachwiana, co może być tragiczne w
skutkach.



>

>
>>>> wa�ny pow�d"?
>>>> je�eli masz
>>>> x = 0;
>>>> y = -x;
>>>> if (x == y) // mo�e przesta�/zacz�� dzia�a�
>>> Niezrozumiales pytania, albo kontekstu. Chodzilo o wazny powod z ktorego
>>> procesor nie moze poprawnie wykonac tego kodu,
>> mo�e tak:
>> bo jest zgodny z IEE754,
> Głupoty. W IEE754 można przechować dokładnie wynik pow(2.0,2.0), to nie
> jest żaden powód, a gdzie dopiero ważny powód.

W IEE754 zero można zapisać na dwa sposoby, póki nie zmienisz standardu
tak będzie.




>
>


--
Darek