W dniu 2013-03-26 23:40, M.M. pisze:
> W dniu wtorek, 26 marca 2013 23:01:23 UTC+1 użytkownik bartekltg napisał:
>> W dniu 2013-03-26 12:25, M.M. pisze:
>>
>>> Niczego to nie zmienia. Logarytm tez mozna policzyc na mantysie o 2 bity
>>> dluzszej (np. na precyzji 66bitow) i wynik bylby dokladny.
>> :)
>> Szkolny przykład.
>> x=1/4;
>> x <- 4*x*(1-x).
>> Powinien wyjść cykl 1/4, 3/4, 1/4...
> Mnie chodziło jeszcze o coś innego, ale świetle tego, że procesory
> liczą zawsze tak samo, to już jest nieważne :)
>
>
>> Dla lepszego związku z tematem dodam, że dwa bity więcej
>> nie spowodują, że zawsze dostaniesz dobry wynik. Dwa
>> bity więcej oznaczają, że najczęściej dostaniesz poprawny
>> wynik.
> No tak, ale to jednak inny przykład i obliczenia pomimo że
> proste, to znacznie bardziej skomplikowane od tych, o jakie
> mnie chodziło. Jeśli mamy N liczb i każda z nich jest sumą
> całkowitych potęg dwójki, wszystkie są dodatnie, razem
> sumują się (dokładnie) do jedynki i mieszczą się w typie, to
> w wyniku poniższych operacji na tych liczbach:
> i = rand( 1 , N )
> j = rand( 1 , N )
> tmp = x[i] * 0.5;
> x[i] -= tmp;
> x[j] += tmp;
> Suma nie powinna odbiegać od jeden? Odpalam jeden tego
> typu program na dobę i po dobie obliczeń nie mam straty
> dokładności.

To czemu nie zrobiłeś tego na intach;>

Już daję kontrprzykład.

X ma dwa elementy.
Za każdym razem losujemy
i=1
j=2

Czyli za każdym razem połowa pierwszego elementu idzie do drugiego.

w k tym kroku
x[1] = 0.5^(k+1)
x[2] = 1 - 0.5^(k+1)

Przy odpowiednim sposobie zaokrąglania pojawi się +-epsylon.


Np jeśli mamy zaokrąglanie w dół, jest klapa.

Pewnie bez trudu zmontujesz przykład, gdzie liczby pozostają
podobnego rozmiaru, a ta jedynka wędruje w keirunku przecinka
i w końcu go mija.

Zaokrąglanie zaokrąglaniem, ale nieprawdą jest to:

>
>> Odpłynęliśmy równie daleko, mimo, że zarówno argument
>> naszego wyrażenia, jak i wynik były zapisywalne dokładnie.
> Hmmm, ale wszystkie pośrednie wyniki też były dokładne? Bo
> w przykładzie o jaki mnie chodzi, wszystkie pośrednie wyniki
> przynajmniej mogą być dokładne.

Nie, nie były dokładne. W najprostszym przypadku z przykładu
powyżej mamy ciągłe dodawanie małego elementu do ~jedynki




A, nie mówiąc już o tym, że sama procedura sumowania może
doprowadzić do błędów!

Dokładność 3 bity:

x= 10 000b + 1b +1b +1b +1b +1b +1b +1b +1b +1b +1b +1b +1b 1b +1b +1b +1b.

Wynik powinien byc 100 000b, a jest 10 000b

pzdr
bartekltg