🚀 go-pugleaf

fly wrote:
> Nie wie dlaczego akurat w 
> mnozeniu jest taki blad.. ma ktos jakis pomysl?

Za pomocą liczb zmiennoprzecinkowych można dokładnie zapisać tylko
skończony zbiór wartości i najpewniej dla (2^32-1)^2 nie ma dokładnej
reprezentacji.

w.

-- 
Tępi głupcy są własnymi nieprzyjaciółmi, gdy dopuszczają
się złych uczynków, których owoce są gorzkie. 

fly napisał(a):
> Hello,
> Probuje wlasnie pomnozyc w asmie takie oto liczby:
> 4 294 967 295 and 4 294 967 295 ;)
> kod:
> ...
> mianownik1 dq 0
> mianownik2 dq 0
> .
> .
> mov dword ptr mianownik1,esi
> mov dword ptr mianownik2,esi
> .
> .
> fild mianownik1
> fild mianownik2
> fmulp
> 
> TDostaje zly wynik, powinno byc tylr: 18446744065119617025
> a jest: 18446744065119617020.
> przegaldam rejestry koprocesora w OllyDbg. Nie wie dlaczego akurat w
> mnozeniu jest taki blad.. ma ktos jakis pomysl?

 Jak już powiedziano, brak precyzji koprocesora. Spróbuj FIMUL. Wynik
zmieściłby się w EDX:EAX, ale jak kto woli ;) Dla celów edukacyjnych
może być FPU.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Prawdziwy, bezpieczny komunikator:                   www.JabberPL.org

Wojciech Muła napisał(a):
> Za pomocą liczb zmiennoprzecinkowych można dokładnie zapisać tylko
> skończony zbiór wartości i najpewniej dla (2^32-1)^2 nie ma dokładnej
> reprezentacji.
-
fajnie, ale...
zrobilem progam ktory ma mi dodawac dwa ulamki, wszystko w zasadzie 
robie na koprocesorze.. no i np, taki przyklad:
123456/234567  +  2345673/3355664. Dokladnosc obliczen jest fatalna..
Nie wiem dlaczego.. Jezeli mianownik i licznik sa mniejsze, okolo 3 
znakow, jest w miare ok, ale zupelnie dokladnie tez nie jest..
w zasadzie po co ten koprocesor skoro jest taki "slaby"..? ;///

pozdr.fly

fly wrote:
> Nie wiem dlaczego..

Już pisałem: liczby zmiennoprzecinkowe reprezentują liczby z pewną
dokładnością.  Tzn. liczba dokładna x jest przybliżana pewną liczbą ze
skończonego zbioru wartości.  Patrząc inaczej: otrzymujesz liczbę (x+e),
gdzie x to wartość dokładna, e - błąd reprezentacji.

> Jezeli mianownik i licznik sa mniejsze, okolo 3 
> znakow, jest w miare ok, ale zupelnie dokladnie tez nie jest..
> w zasadzie po co ten koprocesor skoro jest taki "slaby"..? ;///

W obliczeniach numerycznych wystarcza te kilka(naście) miejsc po
przecinku.  Do obliczeń dokładnych (z zerowym błędem reprezentacji liczb
i operacji arytmetycznych) liczby zmiennoprzecinkowe po prostu się nie
nadają.

Wybrałeś zły środek do realizacji swojego projektu.

w.

-- 
Tępi głupcy są własnymi nieprzyjaciółmi, gdy dopuszczają
się złych uczynków, których owoce są gorzkie. 

Wojciech Muła napisał(a):
> Już pisałem: liczby zmiennoprzecinkowe reprezentują liczby z pewną
> dokładnością.  Tzn. liczba dokładna x jest przybliżana pewną liczbą ze
> skończonego zbioru wartości.  Patrząc inaczej: otrzymujesz liczbę (x+e),
> gdzie x to wartość dokładna, e - błąd reprezentacji.
-
super.. czaje.. mialem to na metodach numerycznych, ale to nie zmiania 
faktu ze chce tego uniknac.. a najwyrazniej uzywajac koprocesora, nie 
jestem wstanie tego osiagnac ;/

> Wybrałeś zły środek do realizacji swojego projektu.
Hmn.. bycmoze, tylko ze akurat dla mniek poczatkujacego w asmie, 
koprocesory wydal sie bardzo przyjazny, instrukcje sa proste no i de 
facto dzialaja, tylko malo precyzyjnie..
obawiam sie ze realizacja tego samego zadania na procesorze, bylaby duzo 
bardziej pracochlonna..
nie mniej jednak, nie omieszkam sprobowac, zobacze najpierw co powie moj 
wykaldowca na temat tej nieszczesnej precyzji i czy zakceptuje moj 
projekt w obecnym ksztalcie.

pozdr.fly

Użytkownik "Wojciech Muła" <wojciech_mula@poczta.null.onet.pl.invalid> 
napisał w wiadomości news:slrne32m1u.1sk.wojciech_mula@cat.tac...
> fly wrote:
>> Nie wie dlaczego akurat w
>> mnozeniu jest taki blad.. ma ktos jakis pomysl?
>
> Za pomocą liczb zmiennoprzecinkowych można dokładnie zapisać tylko
> skończony zbiór wartości i najpewniej dla (2^32-1)^2 nie ma dokładnej
> reprezentacji.
Single precision 1 bit znaku, 23 bity mantysy i 8 bitów wykładnika.
Double precision 1 bit znaku, 52 bity matysy i 11 bitów wykladnika.
To powinno wystarczyć za całe wyjaśnienie tego fenomenu ;-)
Nawet w double 12 bitów wyniku jest obcięte.

pzdr
AK

Artur Kowalski wrote:
>> Za pomocą liczb zmiennoprzecinkowych można dokładnie zapisać tylko
>> skończony zbiór wartości i najpewniej dla (2^32-1)^2 nie ma dokładnej
>> reprezentacji.
> Single precision 1 bit znaku, 23 bity mantysy i 8 bitów wykładnika.
> Double precision 1 bit znaku, 52 bity matysy i 11 bitów wykladnika.
> To powinno wystarczyć za całe wyjaśnienie tego fenomenu ;-)

Tak w połowie. :)  Bo koprocesor x86 normalnie wykonuje obliczenia na
extended double, czyli 64 bity mantysy, 15 wykładnika.  Przynajmniej
tak jest domyślnie ustawiane po wykonaniu finit.

w.

-- 
Tępi głupcy są własnymi nieprzyjaciółmi, gdy dopuszczają
się złych uczynków, których owoce są gorzkie. 

Użytkownik "fly" <ylfly@NOSPAMo2.pl> napisał w wiadomości 
news:e0rg6v$afm$2@atlantis.news.tpi.pl...
> Hello,
> Probuje wlasnie pomnozyc w asmie takie oto liczby:
> 4 294 967 295 and 4 294 967 295 ;)
> kod:
> ...
> mianownik1 dq 0
> mianownik2 dq 0
> .
> .
> mov dword ptr mianownik1,esi
> mov dword ptr mianownik2,esi
> .
> .
> fild mianownik1
> fild mianownik2
> fmulp
>
> TDostaje zly wynik, powinno byc tylr: 18446744065119617025
> a jest: 18446744065119617020.
> przegaldam rejestry koprocesora w OllyDbg. Nie wie dlaczego akurat w 
> mnozeniu jest taki blad.. ma ktos jakis pomysl?
>
> pozdr.fly

jak juz napisalem gdzies wczesniej - dales FINIT? Kiedys mialem identyczny 
problem....;] 

Użytkownik "Wojciech Muła" <wojciech_mula@poczta.null.onet.pl.invalid> 
napisał w wiadomości news:slrne34vqn.14t.wojciech_mula@cat.tac...
> Artur Kowalski wrote:
>>> Za pomocą liczb zmiennoprzecinkowych można dokładnie zapisać tylko
>>> skończony zbiór wartości i najpewniej dla (2^32-1)^2 nie ma dokładnej
>>> reprezentacji.
>> Single precision 1 bit znaku, 23 bity mantysy i 8 bitów wykładnika.
>> Double precision 1 bit znaku, 52 bity matysy i 11 bitów wykladnika.
>> To powinno wystarczyć za całe wyjaśnienie tego fenomenu ;-)
>
> Tak w połowie. :)  Bo koprocesor x86 normalnie wykonuje obliczenia na
> extended double, czyli 64 bity mantysy, 15 wykładnika.  Przynajmniej
> tak jest domyślnie ustawiane po wykonaniu finit.
Fukstycznie jest jeszcze 80 bitowy extended.

Może trzeba coś z RC pokombinować?

pzdr
AK

Artur Kowalski napisał(a):
> Może trzeba coś z RC pokombinować?
-
probowalem, ale sa tylko 3 opcje, zaokragla w dol, w gore i obcina, 
zdaje sie..
zreszta rozmawialem juz z moim prof., powiedzial ze koprocesor to "kupa" 
i mam robic na zwyklym procku i bawic sie z exx'ami.. w dzielenie duzych 
liczb na mniejsze etc.. na tym polega to "cwiczenie" zebysmy sie 
"otrzaskali"..;-)

pozdr.fly

Robert napisał(a):
> jak juz napisalem gdzies wczesniej - dales FINIT? Kiedys mialem identyczny 
> problem....;] 
-
Dalem.. poprostu przy duzych liczbach na ostatnich bitach, wywala 
randomowe wartosci z braku precyzji.. przerobie to na zwyklego proca i 
bedzie ok..

pozdr.fly

Użytkownik "fly" <ylfly@NOSPAMo2.pl> napisał w wiadomości 
news:e0u8vf$76q$1@nemesis.news.tpi.pl...
> Artur Kowalski napisał(a):
>> Może trzeba coś z RC pokombinować?
> -
> probowalem, ale sa tylko 3 opcje, zaokragla w dol, w gore i obcina, zdaje 
> sie..
> zreszta rozmawialem juz z moim prof., powiedzial ze koprocesor to "kupa" i 
> mam robic na zwyklym procku i bawic sie z exx'ami.. w dzielenie duzych 
> liczb na mniejsze etc.. na tym polega to "cwiczenie" zebysmy sie 
> "otrzaskali"..;-)
OK, ma rację. Chyba pamieta czasy gdy FPU nie było nawet w duzych maszynach 
;-)
Sprawdziłem jak RC działa, zaokragla ciekawie zamiast końcówki 20 można
uzyskać 00 lub 30. Chyba matyssa jest w BCD zaookrąglana.

pzdr
AK