On 2012.11.01 11:15, slawek wrote:

> Tzw. maszynowy epsilon (see Wikipedia) wynosi nie więcej niż 1.111E-016 dla
> liczb 64-bitowych.

Na wikipedii jest 2.220446e-16 (zjedź na dół do przykładu)

> Taki wynik łatwo otrzymać nawet naiwnym algorytmem, w
> którym po kolei sprawdzane są w pętli kolejne wartości epsilon - każda
> kolejna nieco (o ułamek procenta) mniejsza od poprzedniej.

A po co taki naiwny algorytm? definicja maszynowego epsilon chyba jest
jasna?

> Algorytm "fast"

O(1) patrz poniżej

> adaptacyjnie zmienia krok itd. - nie ma to znacznego wypływu na wynik, ale
> liczba kroków jest znacznie mniejsza.
>
> Jednak zaglądając do float.h w MS VS C++ można znaleźć definicję
> DBL_EPSILON, wraz ze stosownym komentarzem, 2.22044604925031310000E-016.

I jest to prawidłowa wartość.

> Jest to niemal 2 razy więcej, niż naprawdę wynosi epsilon (obliczony właśnie
> programem skompilowanym w MSVS C++). "This is not a bug, this is
> inaccuracy" - chciałoby się powiedzieć.

Pokaż ten program.

> Zaglądamy dalej - Matlab - tak ostatnio chwalony - ma wbudowaną funkcję
> eps - zgadnijcie co zwraca eps jako wynik liczbowy? Tak, też się zdziwiłem -
> przecież Matlab to Matlab.
>
> Jeszcze raz rzut oka do Wikipedii - jest sobie wyraźnie dobra wartość
> epsilona dla double w tabelce - ale już np. program w Phytonie i wyniki z
> niego - znowu błędne 2.22E-16 . I nie jest to "wina Phytona" - ale po prostu
> błąd w programie.
>
> "Phytonowcy", staff MS i ludzie z MathWorks popełnili jeden i ten sam błąd -
> dzielili przez dwa. Ciąg wartości x[n], jakie otrzymywali, dla dostatecznie
> dużego n nie spełniał nierówności 1.0+x[n] > 1.0.

Nie wiem co tu jest do dzielenia, aby obliczyć maszynowe epsilon nic nie
trzeba dzielić, przykład:

#include <iostream>
#include <stdint.h>
#include <iomanip>

int main()
{
union
{
double f;
uint64_t i;
} u1, u2, u3;


u1.i = 0x3ff0000000000000ul;
// jeden (exponent na 1023 mantysa na zero -- jeden bit z przodu
// mantysy jest domniemany)

u2.i = 0x3ff0000000000001ul;
// jeden i ciupka (ostatni bit mantysy na jeden i jeden bit z przodu
// domniemany)

u3.f = u2.f - u1.f;


std::cout << "Maszynowe epsilon: " << std::setprecision(18) <<
u3.f << std::endl;
}

/home/tomek/roboczy/test$ g++ -O2 -o test test.cpp && ./test
Maszynowe epsilon: 2.22044604925031308e-16

Oczywiście nie widzę sensu wypisywania tej wartości jako decimal (to
tylko przybliżenie).
W C++ jako stałą możesz mieć w ten sposób:
std::cout << std::numeric_limits<double>::epsilon() << std::endl;


--
Tomek
http://www.ttmath.org

do góry

Użytkownik "Tomasz Sowa" napisał w wiadomości grup
dyskusyjnych:k72sqt$gq$...@n...dialog.net.pl...

>Na wikipedii jest 2.220446e-16 (zjedź na dół do przykładu)

A ty przeczytaj tabelę u góry (na tej samej stronie Wikipedii).
Jak na to nie patrzeć - trzeba poprawić - albo u góry, albo u dołu, albo w
obu miejscach.

>A po co taki naiwny algorytm? definicja maszynowego epsilon chyba jest
>jasna?

A po co lepszy? Skoro i tak liczy się w mniej niż sekundę? (Czyli o parę
rzędów wielkości krócej, niż trwało np. napisanie przez ciebie tekstu?)

>I jest to prawidłowa wartość.

Możliwe. Pod warunkiem, że przyjmiemy inną definicję niż podana w samym
pliku float.h.

Wniosek - albo definicja w pliku float.h (z pakietu MSVS) jest błędna, albo
wartość w pliku float.h (ibidem) jest błędna, albo obie są błędne.
I to właśnie (podobnie jak hasło w Wikipedii) wymagałoby wyprostowania.

>Pokaż ten program.

Nie będę ciebie obrażał podejrzeniem, że nie potrafisz. Do sprawdzenia, że
1.0+1.5E-16 > 1.0 to wystarczy ci jedna linijka zaczynająca się od cout.

>Nie wiem co tu jest do dzielenia, aby obliczyć maszynowe epsilon nic nie
>trzeba dzielić, przykład:

Owszem, ale ty nie obliczasz epsilona jako inf { x in R : op(1,x) > 1 },
czyli jako najmniejszej liczby, która w wyniku "operacji dodawania
maszynowego" do liczby 1 daje wynik większy niż 1. Zajrzyj sobie do
Teukolsky'ego - oczywiście masz prawo twierdzić, że są tam bzdury. Ale w
takim razie warto napisać do Teukolsky'ego - i pouczyć go jak ma zmienić
fragment rozdziału.

Prawdą jest (w opisanych warunkach), że (double)1.0 + (double)2.22E-16 >
(double)1.0 , ale prawdą jest też, że np. (double)1.0 + (double)1.5E-16 >
(double)1.0E-16.

Z mojego punktu widzenia, jeżeli mam macierz 1000x1000 a chcę przekształcić
ja na macierz rzadką przeglądając jej elementy i uznając za zerowe te, które
są mniejsze niż eps, to lepiej jeżeli wartości równe DLB_EPSILON zostaną jak
są, bo jeżeli odrzucę pół miliona takich - to może polecieć mi w porywach
pięć miejsc znaczących. Przy epsilon = 1.11E-16 czy uznam za zero, czy
zostawię jak są - wynik sumowania z 1.0 będzie jednakowy i nic nie stracę
jeżeli liczby były 64-bitowe z 53-bitową mantysą.

do góry

On 2012.11.03 12:54, slawek wrote:

>> Na wikipedii jest 2.220446e-16 (zjedź na dół do przykładu)
>
> A ty przeczytaj tabelę u góry (na tej samej stronie Wikipedii). Jak
> na to nie patrzeć - trzeba poprawić - albo u góry, albo u dołu, albo
> w obu miejscach.

Poprawione, ktoś sobie założył że ma 53 bity precyzji a tak naprawdę
jest 52 plus jeden domniemany z przodu ale on 'nie działa w tym
przypadku'. Wrzuciłem także do części talk dowód tego i przykłady
w c++: http://en.wikipedia.org/wiki/Talk:Machine_epsilon
Na razie poprawione dla binary32 i binary64 jak znajdę jutro czas to
przyjrzę się pozostałym.

>> A po co taki naiwny algorytm? definicja maszynowego epsilon chyba
>> jest jasna?
>
> A po co lepszy? Skoro i tak liczy się w mniej niż sekundę? (Czyli o
> parę rzędów wielkości krócej, niż trwało np. napisanie przez ciebie
> tekstu?)

Bo popełniasz błąd który się propaguje w każdej iteracji algorytmu.

>> I jest to prawidłowa wartość.
>
> Możliwe. Pod warunkiem, że przyjmiemy inną definicję niż podana w
> samym pliku float.h.
>
> Wniosek - albo definicja w pliku float.h (z pakietu MSVS) jest
> błędna, albo wartość w pliku float.h (ibidem) jest błędna, albo obie
> są błędne. I to właśnie (podobnie jak hasło w Wikipedii) wymagałoby
> wyprostowania.
>
>> Pokaż ten program.
>
> Nie będę ciebie obrażał podejrzeniem, że nie potrafisz. Do
> sprawdzenia, że 1.0+1.5E-16 > 1.0 to wystarczy ci jedna linijka
> zaczynająca się od cout.

Właśnie mówie pokaż program, bo pewnie przykład robisz obliczając na 80
bitach ;)

>> Nie wiem co tu jest do dzielenia, aby obliczyć maszynowe epsilon
>> nic nie trzeba dzielić, przykład:
>
> Owszem, ale ty nie obliczasz epsilona jako inf { x in R : op(1,x) >
> 1 }, czyli jako najmniejszej liczby, która w wyniku "operacji
> dodawania maszynowego" do liczby 1 daje wynik większy niż 1. Zajrzyj
> sobie do Teukolsky'ego - oczywiście masz prawo twierdzić, że są tam
> bzdury. Ale w takim razie warto napisać do Teukolsky'ego - i pouczyć
> go jak ma zmienić fragment rozdziału.

Definicja z dodawaniem nie jest dobra, trzeba uwzględnić zaokrąglanie.
Możesz dodawać do jedynki 'bardzo malutką wartość' a zaokrąglanie masz
ustawione w górę i wartość ci wyjdzie różna od jeden. Ale to co dodałeś
nie będzie prawidłowym maszynowym epsilonem.

Lepsza jest definicja że maszynowy epsilon dla danego typu to po prostu
różnica
pomiędzy następną *reprezentowalną* liczbą w tym typie za jedynką a samą
jedynką.

> Prawdą jest (w opisanych warunkach), że (double)1.0 +
> (double)2.22E-16 > (double)1.0 , ale prawdą jest też, że np.
> (double)1.0 + (double)1.5E-16 > (double)1.0E-16.

W procesorze masz 80 bitów a nie 64.

--
Tomek
http://www.ttmath.org

do góry

Użytkownik "Tomasz Sowa" napisał w wiadomości grup
dyskusyjnych:k734vm$43g$...@n...dialog.net.pl...

>Poprawione, ktoś sobie założył że ma 53 bity precyzji a tak naprawdę

I dobrze. Przynajmniej jest jakaś spójność. Zajrzałeś wcześniej do standardu
IEEE-754 ? Referencje do źródeł?

>Bo popełniasz błąd który się propaguje w każdej iteracji algorytmu.

Nie ma błędu. Za każdym razem jest na nowo sprawdzanie 1.0+eps > 1.0, tj.
pętla while(1.0 + eps > 1.0) {...}

Nawet jeżeli były jakieś zaokrąglenia wcześniej itd. ("propagował się") - to
spełnienie/niespełnienie warunku zależy wyłącznie od aktualnej wartości
("nie widzi historii").

>Właśnie mówie pokaż program, bo pewnie przykład robisz obliczając na 80
>bitach ;)

Robię obliczenia na przeciętnych PC przy domyślnych ustawieniach
kompilatora - z którym to dostarczany jest plik float.h z DBL_EPSILON takim
jaki tam jest.

To chyba nie moją rolą jest obudować ten DBL_EPSILON jakimiś ifdef-ami, albo
przynajmniej dać komentarz, kiedy jego wartość jest sensowna? ;)

>Definicja z dodawaniem nie jest dobra, trzeba uwzględnić zaokrąglanie.

Definicja z dodawaniem JEST DOBRA - właśnie dlatego, że UWZGLĘDNIA
DODAWANIE. Jako end-usera nie obchodzi mnie, ile i jakich bitów jest gdzie -
mogą być nawet analogowe napięcia w miliwoltach, mogą być natężenia
przepływu syropu, mogą być jakieś q-bity czy p-bity. Obchodzi mnie tylko,
kiedy 1+x policzone na danej maszynce da w okienku wyników 1, choć x nie
było zerem.

>ustawione w górę i wartość ci wyjdzie różna od jeden. Ale to co dodałeś
>nie będzie prawidłowym maszynowym epsilonem.

To co ty nazywasz "maszynowym epsilonem" nie jest "maszynowe" - ale
zwyczajnie "pamięciowe". Jest wielkością charakterystyczną dla /sposóbu/
zapisu liczb w pamięci (tj. w RAM, w rejestrach FPU itd.)

>Lepsza jest definicja że maszynowy epsilon dla danego typu to po prostu

To nie jest lepsza definicja - choć i nie gorsza. To po prostu inna
definicja.

>W procesorze masz 80 bitów a nie 64.

Niekoniecznie. Są różne procesory i różne tryby ich pracy.

do góry

On 03.11.2012 10:14, slawek wrote:
> Użytkownik "Michoo" napisał w wiadomości grup
> dyskusyjnych:k71ct6$fjv$...@m...internetia.pl...
>
>> Jakbyś przed trollowaniem zadał sobie trud jego przeczytania to byś
>> nie znowu pieprzył jak potłuczony. Współczesny sprzęt operuje
>> wewnętrznie na liczbach 80 bitowych. [Chodzi o to, żeby zapewnić
>> dostateczną precyzję na "zwykłym" double.]
>
> I znowu "mowa nienawiści", próba manipulacji - zamiast merytorycznej
> wiedzy.

Ty trollujesz jak karmię trolle - to chyba standard.

>
> Choćby o tym, jak wygląda architektura procesorów Itanium.

I zapomniałem już że czepiasz się "domyślnych" dla innych szczegółów.
Nie mówię o Itanium, nie mówię o NEONach, czy innych FVP. Jeżeli nie
wspomniano inaczej to mówimy na tej grupie o FPU x86.

No chyba, że Ty testowałeś na Itanium i nie raczyłeś o tym wspomnieć?

>
>> Obliczenia są przycinane w momencie konwersji do double, dla pełnej
>> zgodności ze standardem niektóre kompilatory mają specyficzne opcje
>
> Gdyby były obcinane,

Nie obcinane. "Przycinane" - znaczy się redukowanie bez wdawania się w
szczegóły implementacji. (Tryb zaokrąglania można zresztą ustawić.)

>
> One są zaokrąglane - czyli także "w górę", ceil.

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.

>
> I nie dlatego aby uzyskać zgodność ze standardem (dla tej zgodności
> obliczenia musiałyby być przeprowadzane na liczbach 64-bitowych,

Ale FPU nie liczy na 64 bitowych.

> ewentualnie po każdym pojedynczym działaniu arytmetycznym przekształcane
> na 64-bitowe, co da się zrobić np. w gcc jest -ffloat-store).

Tak, właśnie o tym napisałem.

>
>> powodujące to przycięcie po każdej operacji, w przeciwnym razie ciąg
>
> Tym razem ja zachowam się nieładnie: przyciąć... to można palec szufladą.

Loglan jest równie ścisły co mało użyteczny.

>
>> obliczeń w typie double. "Eksperymentalnie" możesz więc otrzymywać
>> bzdury nie mające związku z formatem "double".
>
> Podsumowując - polski "informatyk" jest głęboko wierzący: woli wierzyć w
> swoje wewnętrzne głębokie przekonanie we własną nieomylność , niż
> zmierzyć się z rzeczywistością i zauważyć chociażby tak prosty fakt, jak
> że 2.22E-16 nie równa się 1.11E-16.

Gdzie ja się odnosiłem do tej wartości? Ja tylko napisałem ogólnie, że
liczenie bez uwzględnienia platformy może dawać dziwne wyniki. To Ty
wspomniałeś, że z manuala coś wynika, mimo, że go chyba nie czytałeś.

>
> "jednak dodanie, używając liczb double, 1.5E-16 i 1.0 daje więcej
> niż 1.0".

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.


> Niemniej szacun - dołączyłeś do całkiem pokaźnego stadka osobników,
> którym żaden jakiś tam Eksperyment nie będzie będzie mówił co mają robić.

Wydaje ci się.

--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" napisał w wiadomości grup
dyskusyjnych:k73isd$sfj$...@m...internetia.pl...
>I zapomniałem już że czepiasz się "domyślnych" dla innych szczegółów. Nie
>mówię o Itanium, nie mówię o NEONach, czy innych FVP. Jeżeli nie wspomniano
>inaczej to mówimy na tej grupie o FPU x86.

Podobno "zwykłe procesory" lepiej liczą instrukcjami SSE niż "normalnymi".
Sam się zdziwiłem.

>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? Wiem, marudzę.

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

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.

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

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

do góry

W dniu sobota, 3 listopada 2012 22:23:18 UTC+1 użytkownik slawek napisał:
> Użytkownik "Michoo" napisał w wiadomości grup
>
> dyskusyjnych:k73isd$sfj$...@m...internetia.pl...
>
> >I zapomniałem już że czepiasz się "domyślnych" dla innych szczegółów. Nie
>
> >mówię o Itanium, nie mówię o NEONach, czy innych FVP. Jeżeli nie wspomniano
>
> >inaczej to mówimy na tej grupie o FPU x86.
>
>
>
> Podobno "zwykłe procesory" lepiej liczą instrukcjami SSE niż "normalnymi".
>
> Sam się zdziwiłem.
>
>
>
> >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? Wiem, marudzę.
>
>
>
> >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!
>
>
>
> 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.
>
>
>
> 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.)
>
>
>
> 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).

korzysci z tej dyskusji sa bo wreszcie jakis ciekawy temat, 80 bitowe sa chyba nie
tylko rejestry fpu, bo sa chyba polecenia umozliwiajace
zapis tego jako 10bajt do ram

do góry

Użytkownik "Roman W" <r...@g...com> napisał w wiadomości:

> Wystarczy wynik obliczen przepuscic pare razy przez jakies exp, pow
> czy log i epsilonik z 1E-16 robi sie 1E-13.

Doklanie. Przeciez o tym w gruncie rzeczy mowie (stad to umowne pomnozenie przez
100).
Poza tym zburaczaly hrabia slawek chyba zapomnial o czyms tak podstawowym problemie
w numeryce jak kumulacja bledow.
Przy zlym algorytmie (nie dbajacym o to aby ta kumulacja sie znosila) pomnozenie
"maszynowego"
epsilona nawet przez przyslowiowy milion nie wystarczy :)

Ja sie juz na tym (numeryce/matmie) neistety nie znam (numeryka zajmowalem sie rowno
25lat temu),
ale skupainie sie na maszynowym epsilonie chyba jednak i dzis charakretyzuje
(przynajmniej powinno)
numeryczne zbureczanie.

AK

do góry

Użytkownik "slawek" <h...@s...pl> napisał:

> Masz 100% racji - w komunistycznym systemie, na sprzęcie made in republika ludowa

Glupi zburaczaly palancie :)
Odra 1325/1305 to byl klon rodziny jak najbardziej angielskiego komputera
(a wlasciwie calej rodziny) ICL 1900 :)

PS: I nie wyjezdzaj mi tu z komunizmem, bo moje inicjaly nie sa przypadkowe.

AK

do góry

kenobi <p...@g...com> wrote:

> nie czytalem chasla w wiki i nie bardzop che

Czy ty się kiedyś ośle nauczysz wycinać cytaty? Czy przerasta to twoje
zdolności intelektualne?

> róznica miedzy doublami w epsilonach? ta roznica jest chyba stała, czy tez wchodza
tu jakies komplikacje powodujace ze licZyc sie moze cos innego niz ziarnistosc
double? (mozliwe ze to juz jest tu napisane ale nie mialem sily sie wglebiac)

Wycinać cytaty i zawijać wiersze.

http://evil.pl/pip/netykieta.html
http://informatyka.3bird.net/netykieta.html

Nie wracaj dopóki się nie douczysz zasad korzystania z Usenetu.

--
Gof
http://www.chmurka.net/

do góry