W dniu 2013-03-25 19:36, M.M. pisze:
> W dniu poniedziałek, 25 marca 2013 18:40:31 UTC+1 użytkownik AK napisał:
>> Otoz nie.
>> Moze sie okazac, ze ten koproc/kompilator ktory akurat daje dokladnie
>> w tym przypadku pow(3.0,2.0), w wiekszosci innych przypadkow
>> sie "myli", natomiast ten gdy ten gorszy liczy "dobrze".
> No dobrze, może czegoś się dowiem, ale kompletnie nie wiem dlaczego miałby
> na pozostałych liczyć dokładniej, jeśli na tym jednym przypadku nie potrafi
> nadać poprawnych wartości wszystkim bitom?
>


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.

>
>>> Być może taka dokładność jest okupiona wolniejszym wykonaniem.
>> Byc moze, a byc moze nie (np inna reprezentacja wewnetrzna,
>> inna dlugoscia akumulatora itp).
> Tego nie wiem, tak sobie gdybam tylko.
>


albo inny algorytm obliczania danej funkcji.

>
>> Zalosc tylko bierze, ze na studiach tak podstawowej rzeczy nie ucza jak
>> traktowanie liczb fp w jezykach programowania jako ZAWSZE
>> obarczonych pewnym bledem.
> No dobrze, ale dlaczego nie wziąć takiej liczby jaką podał programista, czy
> takiej jaką podał użytkownik wprowadzający dane do programu? Dlaczego jeśli
> programista wpisał 1.0, to kompilator ma zrobić z tego 1.00000000000101, bo
> i tak i tak to jest przybliżone?
>

1.0 prawdopodobnie nie ale już 1.1 to być może

tak samo X + 1 + 1 - 2 dla niektórych wartości może wcale nie dać X

w przypadku reprezentacji zmiennoprzecinkowej nie działa wiele twierdzeń
które uczą w podstawówce: np przemienność dodawania, mnożenia,
rozdzielność mnożenia itp.

>
>> Ta "niedokladnosc" nalezy traktowac nie jako neidoskonalosc
>> kompilatora/procesora ale jako NATURE tych liczb.
> Nadal nie rozumiem, dlaczego w mnożeniu przez 0.25 zwyczajnie nie
> przesunąć bitów, ale przesunąć i na koniec jeszcze dokleić 2-3 losowe
> bity?

przeanalizuj reprezentację, mnożenie liczb zmiennoprzecinkowych przez
dwa wcale nie polega na przesunięciu bitów
>
>
>> Owszem, ciagle w kompilatorach dazy sie do uleopszen w celu
>> molziwie najwiekszej dokladnosci/mozliwie najwiekszemu zneutralizowaniu
>> tej CECHY fp, ale absolutnie nie nalezy tego uwazac za
>> "zalatwienie" problemu. (Przyklad ostatnich ulepszen dla Pythona
>> na koncu).
> Ogólnie jest tak jak piszesz i zgadzam się że nie można. Ale na niektórych
> argumentach operacje zmiennoprzecidnkowe powinny dawać dokładne wyniki.

dlaczego?
dlaczego tylko dla niektórych a nie dla wszystkich
ponieważ nie da się (ze względu na reprezentację) podawać dokładnych
wyników to minimalizuje się błąd średni a nie tylko dla wybranych argumentów

oczywiście można "tablicować" niektóre wartości funkcji ale to nie
zawsze będzie dobrze, ktoś może narzekać że funkcja jest w tych
miejscach nieciągła.


> Jeśli nie dają dokładnych wyników, to ja to nazywam po imieniu: "są
> mniej dokładne" - nie popełniam tutaj żadnego błędu. Chętnie czegoś nowego
> się nauczę o obliczeniach na liczbach zmiennoprzecinkowych, ale w
> tym konkretnym przypadku sprawa raczej jest oczywista.
>
>> a tam w pierwszym algorytmie - simplex - jak byk stoi cos w rodzaju
>> if abs(x - y) <= EPS then // czyli odpowiednik x == y
> Myślę że każdy z piszących na tę grupę wie iż w ogólności tak należy
> porównywać liczby zmiennoprzecinkowe. Mnie chodziło o bardzo szczególny
> podzbiór operacji na liczbach zmiennoprzecinkowych. Powiem więcej, mam
> napisaną procedurę w której używam na ostro if( x == y ). Napisałem ją
> będąc świadomy zagrożeń. Ale z drugiej strony wiedziałem, że nie ma żadnego
> ważnego powodu, z którego procesor nie może na moich argumentach dać
> dokładnego wyniku.

"ważny powód"?
jeżeli masz
x = 0;
y = -x;
if (x == y) // może przestać/zacząć działać


Skompilowałem, zrobiłem test i okazało się, że na
> docelowej architekturze działa poprawnie. Na innych niż docelowa nie
> działa poprawnie, więc tam mogę skorygować błędy taką techniką jaką
> przytoczyłeś, albo jakąś inną.
>
> Pozdrawiam
>
>


--
Darek

do góry

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.


> 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, a nie wazny powod z ktorego
nie mozna w programach numerycznych porownywac na ostro.

Pozdrawiam

do góry

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

do góry

Użytkownik "darekm" <d...@e...com> napisał:

> bo zachowuje wsteczną kompatybilność

100% racji.
To jest bardzo czesto jeden z najwazniejszych powodow zaniechania "ulepszen".

AK

do góry

mi calkiem fajnie pisało sie
w kodzie maszynowym

char asm_dot_fpu_[] =
{
0x55,
0x89, 0xE5,
0x8B, 0x45, 0x08,
0x8B, 0x55, 0x0C,
0xD9, 0x00,
0xD8, 0x0A,
0xD9, 0x40, 0x04,
0xD8, 0x4A, 0x04,
0xD9, 0x40, 0x08,
0xD8, 0x4A, 0x08,
0xDE, 0xC1,
0xDE, 0xC1,
0x5D,
0xC3
};

cast na wskaznik do funkcji i bang! działa,
ale pozniej odkryłem przez rtdsc jakies
opoznienia z tym zwiazane (do dzis nie wiem
co to jest i czy da sie ominac bo gdyby sie
dało to chetnie bym do tego wrocił) i teraz od czasu do czasu pisze wzglednie
normalnie czyli nasmem

do góry

Pomyliles grupy.

FUT: pl.soc.masochizm, pl.soc.poj...izm

AK

PS: sie doucz. po cholere nadmiarowe 0x55, 0x5D

------------------------------------------

Użytkownik "firr kenobi" <p...@g...com> napisał w wiadomości
news:c68f6015-bcb5-4ca3-8e40-57dd0d735b80@googlegrou
ps.com...
mi calkiem fajnie pisało sie
w kodzie maszynowym

char asm_dot_fpu_[] =
{
0x55,
0x89, 0xE5,
0x8B, 0x45, 0x08,
0x8B, 0x55, 0x0C,
0xD9, 0x00,
0xD8, 0x0A,
0xD9, 0x40, 0x04,
0xD8, 0x4A, 0x04,
0xD9, 0x40, 0x08,
0xD8, 0x4A, 0x08,
0xDE, 0xC1,
0xDE, 0xC1,
0x5D,
0xC3
};

cast na wskaznik do funkcji i bang! działa,
ale pozniej odkryłem przez rtdsc jakies
opoznienia z tym zwiazane (do dzis nie wiem
co to jest i czy da sie ominac bo gdyby sie
dało to chetnie bym do tego wrocił) i teraz od czasu do czasu pisze wzglednie
normalnie czyli nasmem

do góry

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.

do góry

W dniu wtorek, 26 marca 2013 14:48:52 UTC+1 użytkownik AK napisał:
> Użytkownik "darekm" napisał:
> > bo zachowuje wsteczną kompatybilność
> 100% racji.
No dobra, ale dlaczego to jest racja? Nie ma gwarancji dokładnego wyniku
na obliczeniach zmiennoprzecinkowych, czyli DOBRZE napisane programy
numeryczne powinny nadal działać, albo przynajmniej się kompilować,
na procesory ze lekko zmienioną dokładnością obliczeń.

> To jest bardzo czesto jeden z najwazniejszych powodow zaniechania "ulepszen".
W ogóle tak, ale w tym przypadku nie wydaje się aby taka argumentacja
była dobra. W końcu różne procesory liczą z różną dokładnością, a wiele
programów działa poprawnie po przeniesieniu wersji binarnej.


Pozdrawiam

do góry

On Tuesday, 26 March 2013 17:43:21 UTC+1, M.M. wrote:
> W dniu wtorek, 26 marca 2013 14:48:52 UTC+1 użytkownik AK napisał:
>
> > Użytkownik "darekm" napisał:
>
> > > bo zachowuje wsteczną kompatybilność
>
> > 100% racji.
>
> No dobra, ale dlaczego to jest racja? Nie ma gwarancji dokładnego wyniku
> na obliczeniach zmiennoprzecinkowych, czyli DOBRZE napisane programy
> numeryczne powinny nadal działać, albo przynajmniej się kompilować,
> na procesory ze lekko zmienioną dokładnością obliczeń.

Nie. W przypadku obliczeń zmiennoprzecinkowych obowiązuje standard IEEE i wszystkie
szeroko używane procesory się do niego stosują. Ten standard określa jak procesor ma
obliczać i o ile się mylić :)

> > To jest bardzo czesto jeden z najwazniejszych powodow zaniechania "ulepszen".
> W ogóle tak, ale w tym przypadku nie wydaje się aby taka argumentacja
> była dobra. W końcu różne procesory liczą z różną dokładnością, a wiele
> programów działa poprawnie po przeniesieniu wersji binarnej.

Nie. Polecam zapoznać się: http://en.wikipedia.org/wiki/Ieee_floating_point
Każdy procesor który to implementuje (a ogromna większość implementacji matematyki
zmiennoprzecinkowej implementuje ten standard) musi liczyć dokłądnie tak samo. Jak
nie liczy tak samo, to masz np. słynny Pentium bug.

AdamK

do góry

W dniu wtorek, 26 marca 2013 19:02:08 UTC+1 użytkownik Adam Klobukowski napisał:
> Nie. W przypadku obliczeń zmiennoprzecinkowych obowiązuje standard IEEE i
> wszystkie szeroko używane procesory się do niego stosują. Ten standard
> określa jak procesor ma obliczać i o ile się mylić :)
Była mowa o zwiększaniu dokładności i o ulepszeniach, czyli standard
zabrania poprawy dokładności?


> Nie. Polecam zapoznać się: http://en.wikipedia.org/wiki/Ieee_floating_point
> Każdy procesor który to implementuje (a ogromna większość implementacji
> matematyki zmiennoprzecinkowej implementuje ten standard) musi liczyć
> dokłądnie tak samo. Jak nie liczy tak samo, to masz np. słynny Pentium bug.
Sprawdzałem pary kompilator/procesor. Właściwie to rzadko zdarzało się, aby
wyniki były takie same. Jeśli procesory liczą tak samo, to znaczy że
kompilatory generują różny kod. Będę musiał posprawdzać co się dzieje po
przeniesieniu wersji binarnej.

Pozdrawiam

do góry