Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:k6vusd$o7$...@n...task.gda.pl...

>I bardzo dobrze, ze 2 razy wiecej.

Potrafisz to uzasadnić?

Zwłaszcza w kontekście np. takiego fragmentu:

if (x >= DBL_EPSILON)
s = 1.0 + x ;
else
s = 1.0;

Jeżeli x jest typu double, to przy prawidłowej wartości DBL_EPSILON wszystko
jest ok, czyli tak, jak to wynika z definicji (patrz np. Numerical Recipes).

Poprawna wartość to ta która jest zgodna z wybraną definicją. Definicja MS
sprowadza się do inf { x : op(1,x) > 1 } .

W przeciwnym razie musielibyśmy oboje się zgodzić, że twój szef ma prawo np.
wypłacić ci tylko połowę pensji - "definicja" jaka jest w umowie o pracę
jest przecież tylko dla picu - dwa razy więcej, dwa razy mniej - co za
problem?

do góry

Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:k6vv24$15r$...@n...task.gda.pl...

>Ano wlasnie ! (slowem sedno).

A konkretnie? Co masz na myśli?

Ja rozumiem, że niektórzy nie wyszli poza liczeniem sprzedanych jabłek (ew.
sprzedanych kredek, komputerów, ton węgla). I że do tego wystarczą liczby z
dwoma miejscami po przecinku.

Jednak tym razem - przypomina się "baza danych szlauchów i kaloszy" - nie
dyskutujemy na ten temat. Tylko na temat: "jak to możliwe, że epsilon w
float.h jest dwukrotnie zawyżony wobec tego jaką wartość trywialnie łatwo
wyliczyć opierając się na podanej definicji". Oraz na temat: "czy należy
poprawić hasło w Wikipedii, w której jest epsilon dwa razy mniejszy niż we
float.h".

No, ale rozumiem że na poziomie abstrakcji jaki sobą reprezentujesz, to dwa
razy w tę... czy dwa razy we w tę... to mało istotne, prawda?

do góry

Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:k700o6$52t$...@n...task.gda.pl...

>Wystarczy miec orientacje o rzedzie "maszynowego" epsilona.
>Potem go pomnozyc _przynajmniej_ prze 100 ;) i uzywac
>w _normalnej_ (a nie skrajnej) numeryce.

Na poziomie gimbusa - tak, wystarczy.

Na poziomie "ekstremalnej numeryki" - nie masz.

Zgadnij czym się zajmują profesjonaliści.


>Skad niby wiadomo, ze tam bedzie w ogole IEEE ?

Ze specyfikacji sprzętu? Z manuala? Ja tam się "nie znam" - ale co to jest
te IEEE/ISO/ANSI/PN ?

>Mowie to jako programista pracujacy jeszcze na Odrze.
>Na tej Odrze podejscie przez ciebie prezentowane
>byloby srogo ukarane (nie tylko niedzialaniem programow).
>Jedynym z Was dwoch, ktory utrzymal by sie w "pracy" bylby
>Bartek.

Masz 100% racji - w komunistycznym systemie, na sprzęcie made in republika
ludowa - na którym nota bene np. wyliczano ile traktorów będzie produkować
Ursus w 2020 roku - Bartek dawałby sobie radę doskonale. Na twoje i Bartka
nieszczęście nie mamy już komunistycznego systemu. Jakby to określić...
system się zmienił. I nie chodzi o przesiadkę z George na Windows 8.

Oczywiście - jak baaardzo chcecie - to napiszcie sobie z Bartkiem emulator
Odry, a może i RIAD-a. Jak wam nie wystarcza pielęgnowanie wspomnień o
pierwszym gumiaku i atarynce z Peweksu. Ale wtedy wasze zdanie będziemy
cenić mniej więcej tak jak i inne eksponaty muzealne.

>wtret do Bartka o siostrze - twoich przeprosin nie zauwazylem) _zawsze_

Bartek napisał o tym że mam cyt. "syf". To jest pomówienie. Ja napisałem w
odpowiedzi dwa prawdziwe zdania. Jedno: "nie mam syfilisu" . Drugie: "nie
znam twojej siostry". Domyślanie się związku przyczynowo-skutkowego przez
Bartka było nieuprawnionym rozumowaniem. Przepraszać nie mam za co. Owszem,
Bartek powinien przeprosić i powinien wiedzieć za co. Albo - jeszcze
lepiej - nie przepraszać i po prostu nie próbować używać wulgaryzmów, gróźb,
słów odnoszących się do przemocy fizycznej i ogólnie "mowy nienawiści".

>powinno sie dobierac w scislym zwiazku z natura problemu/algorytmu
>numerycznego i z natury swej powinien on byc o wiele wyzszy
>od precyzji maszynowej.

Każdy powinien być piękny, młody i bogaty.

Rozumiesz pojęcia "postawa życzeniowa", "kompromis", "konieczność",
"ograniczenia", "budżet"? Jeżeli tak - to nie muszę więcej pisać. Jeżeli
nie - to nie ma sensu abym pisał.

do góry

W dniu piątek, 2 listopada 2012 08:37:30 UTC użytkownik AK napisał:

> Bo prawdziwy epsilon moj drogi zburaczaly "hrabio" (vide chamski
> wtret do Bartka o siostrze - twoich przeprosin nie zauwazylem) _zawsze_
> powinno sie dobierac w scislym zwiazku z natura problemu/algorytmu
> numerycznego i z natury swej powinien on byc o wiele wyzszy
> od precyzji maszynowej.

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

RW

do góry

W dniu piątek, 2 listopada 2012 09:49:26 UTC+1 użytkownik slawek napisał:
> Użytkownik "AK" napisał w wiadomości grup
>
> dyskusyjnych:k6vusd$o7$...@n...task.gda.pl...
>
>
>
> >I bardzo dobrze, ze 2 razy wiecej.
>
>
>
> Potrafisz to uzasadnić?
>
>
>
> Zwłaszcza w kontekście np. takiego fragmentu:
>
>
>
> if (x >= DBL_EPSILON)
>
> s = 1.0 + x ;
>
> else
>
> s = 1.0;
>
>
>
> Jeżeli x jest typu double, to przy prawidłowej wartości DBL_EPSILON wszystko
>
> jest ok, czyli tak, jak to wynika z definicji (patrz np. Numerical Recipes).
>
>
>
> Poprawna wartość to ta która jest zgodna z wybraną definicją. Definicja MS
>
> sprowadza się do inf { x : op(1,x) > 1 } .
>
>
>
> W przeciwnym razie musielibyśmy oboje się zgodzić, że twój szef ma prawo np.
>
> wypłacić ci tylko połowę pensji - "definicja" jaka jest w umowie o pracę
>
> jest przecież tylko dla picu - dwa razy więcej, dwa razy mniej - co za
>
> problem?

kwestia moze byc w tym ze tamten tekst
z naglowka to moze byc nie tyle definicja
co komentarz przyblizona ilustracja

np mozliwe ze wynik (1 + epsilon != 1)
moze zalezec od jakiegos konfigurowalnego
stanu fpu (choc nie wiem co by to moglo
byc, sa rozne sposoby zaokraglania wynikow
przy dodawaniu doubli? chyba nie)

pozatym jednak niechybnie masz racje
jesli okazuje sie ze ten 2.2 nie jest
najmniejsza liczba, tylko 1.1 tez dziala;

moze jednak 2.2 dziala w jakichs innych
wypadkach (albo inny stan fpu albo jakies
inne przypadki do ktorych potocznie
moglbbyc uzywany taki epsilon i 1.1
tam sie nie lapie)

do góry

przy tym jak rozumiem taki epsilon moze byc uzyteczny przy sprawdzaniu bledow zkresu
(a raczej wartos ie tym czasem zajac bo
jak nie to bledy moga po prostu wchodzic,
nawet w grafice mozna miec male rozjazdy i czlowiek o tym nie wie , a bez nich moglo
by wygladac lepiej

Choc i tak nie wiem czy asserty dla takiego zakresu robi sie to wlasnie przy pomocy
tej stalej czy inaczej

do góry

Użytkownik "kenobi" napisał w wiadomości grup
dyskusyjnych:f1c06cb8-0345-44a8-8207-a4773d21ebf8@go
oglegroups.com...

>pozatym jednak niechybnie masz racje
>jesli okazuje sie ze ten 2.2 nie jest
>najmniejsza liczba, tylko 1.1 tez dziala;

No właśnie rzecz w tym, że mam-i-nie-mam. Spróbuję uporządkować, ale
potrzebna mi jest definicja op(a,b). Funkcję op(a,b) definiuję jako wynik
"dodawania" wykonywanej na danym komputerze. W ten sposób nie musi być nawet
op(2,2) == 4, bo op(a,b) nie jest sumą liczb a+b w sensie matematycznym.

I teraz mamy 3 "epsilony":

1. Liczbę x, która jest najmniejszą liczbą spełniającą nierówność op( 1.0,
x ) > 1.0 .
2. Liczbę y, która jest największą liczba spełniającą równanie op( 1.0, y )
== 1.0 .
3. Liczbę z, która wynosi z = q - 1.0, gdzie q jest najmniejszą liczbą
zapisywalną w określony sposób i spełniającą warunek q > 1.0 .

Uwaga: odejmowanie w pkt. 3. należy rozumieć abstrakcyjnie, czyli ściśle
matematycznie.

Liczby x oraz y są różne na n-tym miejscu po przecinku i dlatego traktuję
je - choć niesłusznie - jako ten sam epsilon. Gdyby zwiększać ilość bitów
mantysy do nieskończoności, to granicznie stałyby się identyczne (i równe
zeru).

Liczba z jest, w bardzo dobrym przybliżeniu, 2 razy większa niż z. I tę
właśnie liczbę Bartek nazywa epsilonem. Ok, też można. Choć jest to jednak
inna definicja niż np. w Numerical Recipes, czyli dość popularnym
podręczniku nt. metod numerycznych (takim sobie, ale znacznie lepszym niż
np. podręcznik Jankowskich) i niż "miał na myśli artysta" uwieczniający się
komentarzem we float.h.

Fakt, że z jest około dwukrotnie większy niż x jest trudno wytłumaczalny
bez - czego właśnie Bartek nie potrafił wyjaśnić - wiedzy o tym, że
obliczenia FPU są robione na 80 bitowych a nie 64 bitowych liczbach float
point. Tzn. normalne liczby double mają mantysę 53 bitową, ale wewnętrznie
FPU (zmutowany Intel 80287) liczy z mantysą 63 bitową. Zaokrąglanie op(1,x)
następuje "do najbliższej", więc w ten sposób w jako wynik osiągana jest
liczba q > 1.0 - "brakującą połówkę z" dostajemy w trakcie konwersji z
mantysy 63 bitowej na 53 bitową.

Przy "różnych opcjach kompilatora(ów)" da się wymusić czasem jakieś double
double, quarduple czy extended - oraz rygorystyczne obcinanie dokładności
FPU do 53 bitów. Istnieją też prawdziwe procesory 128 bitowe i takie tam.
Więc rzeczywiście nie jest bezpiecznie polegać na wstępnie ustalonym
DBL_EPSILON - a zwłaszcza (co już pisałem) brać dosłownie wszystkich cyferek
jakie tam we float.h są wypisane.

W Wikipedii jest jak wół epsilon 1.11E-16 (dla double), ale na tej samej
stronie WWW jest przykład w Phytonie z wynikiem 2.22E-16. Już samo to
wymagałoby sprostowania, przecież Wikipedia nie jest czymś czego nie można
poprawiać - zwłaszcza jeżeli się aspiruje do bycia - jak Bartek - ekspertem
w dziedzinie.

do góry

Użytkownik "kenobi" napisał w wiadomości grup
dyskusyjnych:bfb1ea97-878d-42fe-a66e-675602143c4a@go
oglegroups.com...

>nawet w grafice mozna miec male rozjazdy i czlowiek o tym nie wie , a bez
>nich moglo by wygladac lepiej

Z mojego doświadczenia wiem, że "małe rozjazdy" nie mają znaczenia jeżeli:

A. nie kumulują się;
B. nie są "dziurami" - np. dwie "niemal" stykające się ściany "trochę źle
zszyte" - i np. przeciwnik widzi nas jakby miał RTG w oczach.

do góry

On 02.11.2012 10:45, slawek wrote:
> Użytkownik "AK" napisał w wiadomości grup
>
>> Skad niby wiadomo, ze tam bedzie w ogole IEEE ?
>
> Ze specyfikacji sprzętu? Z manuala?

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. [*]

Obliczenia są przycinane w momencie konwersji do double, dla pełnej
zgodności ze standardem niektóre kompilatory mają specyficzne opcje
powodujące to przycięcie po każdej operacji, w przeciwnym razie ciąg
obliczeń ma większą dokładność niż to wynika z wykonania kolejnych
obliczeń w typie double. "Eksperymentalnie" możesz więc otrzymywać
bzdury nie mające związku z formatem "double".


[*] Chodzi o to, żeby zapewnić dostateczną precyzję na "zwykłym" double.

Btw: Na porządnych kompilatorach masz pełną precyzję dostępną przez
"long double" o długości 12 bajtów.


--
Pozdrawiam
Michoo

do góry

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.

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

>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, efektu nie byłoby. Kiepsko jak widzę z liczeniem na
palcach.

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

I nie dlatego aby uzyskać zgodność ze standardem (dla tej zgodności
obliczenia musiałyby być przeprowadzane na liczbach 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). Ale z oczywistej przyczyny,
że nie da się zapisywać liczb 80-bitowych w 64 bitach bez utraty informacji.

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

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

Tak Michoo, mógłbyś być nawet papieżem i upierać się że Ziemia jest płaska,
albo że Ziemia stoi Słońce robi epicykle, albo że Ziemia jest w miejscu
spełniającym mocną zasadę kosmologiczną - ale to nie zmienia faktu "jednak
dodanie, używając liczb double, 1.5E-16 i 1.0 daje więcej niż 1.0".

A jednak się dodaje! ... Teraz czekam na stosik.

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

do góry