On 03.11.2012 22:22, slawek wrote:
> Użytkownik "Michoo" napisał w wiadomości grup
> dyskusyjnych:k73isd$sfj$...@m...internetia.pl...
>
>> Nie chce mi się sprawdzać, ale oidp jest to zaokrąglanie do
>> najbliższego. Zresztą tylko taka forma by miała sens przy tej dyskusji
>> o dokładności.
>
> Czyli jednak są zaokrąglane - a nie przycinane?

Są przycinane do 64 bitów afaik na 4 sposoby:
- down
- up
- near
- trunc

Domyślne jest near.

Wolę słowo "przycinane", niż zaokrąglane, bo inaczej mamy "zaokrąglanie
przez obcięcie bitów", a tak jest "przycięcie bitów (z zaokrągleniem)".

> Wiem, marudzę.

Marudzisz, zwłaszcza, że najpierw błędnie napisałeś o zaokrąglaniu w górę.

>
>> Tak. I jak Ci już wspomniano - w praktyce nie interesuje programisty
>> dokładność maszynowa a odległość między dwiema liczbami, czyli 2*e.
>> Komentarz jest błędny w nagłówku a dobry w matlabie.
>
> Po drugie - czyli jednak mam rację - jest błąd w float.h ? Jest!

Jest, ale wynika z czego innego niż myślisz.

>
> Po pierwsze - właśnie sam napisałeś, że to co jest równe 2.2E-16 to
> odległość między dwiema liczbami i nie jest to epsilon. I znowu mam
> rację?! Dziwne.

Nie epsilon _maszynowy_ na FPU x86, które jak już wspomniano jest 80
bitowe. To, że dodanie ~połowy tej wartości wystarcza dla uzyskania
1.0+e!=1.0 wynika z tych 80 bitów i polityki near. W szerszym typie
wynik masz bliżej (1.0+2.2E-16) niż 1.0 więc jest zaokrąglane do
(1.0+2.2E-16) w momencie przycięcia do double. Jeżeli byś operował na
czystym double (64 bit) to zabraknie ci bitów na reprezentację tej sumy
i afaik nadal dostaniesz 1.0.

W związku z tym:
- 2.2E-16 nie jest najmniejszą wartością jaka na FPU x86 spowoduje
zajście nierówności. Jest najmniejszą taką wartością w typie double.

>
> Po trzecie - zamiast napisać, cyt., "nie interesuje programisty" -
> powinieneś napisać, iż ciebie nie interesuje. (Czyli po prostu nie
> uogólniać swoich opinii jako opinii wszystkich programistów, bo są to -
> być może nawet bardzo celne - ale wyłącznie twoje własne spostrzeżenia.)

float.h jest częścią standardu i odnosi się do standardowych typów
float(32 bit) i double (64 bit). Gdyby ten nagłówek oparto o corner-case
x86 to programista piszący np na VFP by się bardzo zdziwił, że ten
epsilon nie działa.

Na którymś z egzotycznych procesorów (niagara? alfa?) można było
ustawiać zaokrąglanie dla każdego rozkazu fpu. Wyobrażasz sobie, że w C
trzeba by przy każdej operacji float/double podawać prefix jak to
zaokrąglić?


>
> Podsumowując - dobrze jeżeli jest już poprawka w Wikipedii - to
> pozytywny rezultat dyskusji. A problem jest dużo bardziej poważny, niż
> mi się wydawało - po prostu nie wiadomo ile bitów mantysy jest naprawdę
> użyte (tj. czy będą użyte 64 bitowe liczby double, czy 80 bitowe
> rejestry FPU, zależy od humoru kompilatora).

I zazwyczaj nie ma to znaczenia. Nikt nie robi poważnej numeryki
opierając się o to, że na x86 połowa epsilona double wystarcza.

--
Pozdrawiam
Michoo