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