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?


> > 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.


> 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?


> 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?


> 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 zmiennoprzecinkowe powinny dawać dokładne wyniki.
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. 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