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.

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)

>
>
>> 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,
bo zachowuje wsteczną kompatybilność

a nie wazny powod z ktorego
> nie mozna w programach numerycznych porownywac na ostro.
>
> Pozdrawiam
>


--
Darek