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



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