Posted By: pivson (Pijte pivo, je zdrave !!!) on 'CZprogram'
Title:     Re: Zaokrouhlovani cisla typu Extendedy
Date:      Fri May 10 20:05:22 2002

>  Tohle se tu resilo cca pred nejakou relativne nedavnou dobou, a ... FPU 
> dokaze naprosto presne vyjadrit jakekoli cele cislo (rozumne velke - tzn. do
> velikosti mantisy). 
Jasne, ja to bral jen jako priklad (ilustraci). Obecne cely cisla vyjadris 
presne, to se shodnem. Ono taky pokud se budes pohybovat v N/Z cislech, tak 
ve vetsine pripadu ani nepotrebujes epsilon (viz niz).
 
>  Jestli vyse uvedene spravne chapu, tak tvrdis, ze if (abs(a-b) < KONST_EPS)
> je spravny zpusob porovnani pro jakkoli velke/male a, b ? Presnost se ti
> prave 
> ztraci v prvnim bitu za mantisou, ktera na exponentu zavisla je. Zkus
> loadnout 
> double, ulozit ho dvakrat jako float, jednou pri nastavenem zaokrouhlovani 
> dolu, podruhe nahoru, loadni znovu a spocitej rozdil.
Pokud jsou a,b 'ruzna' hodne od sebe, pak je jejich rozdil sam o sobe velkej, 
tutiz porovnani s E vyjde 'tak jak ma' (tedy to abs bude vetsi). Ztraci se 
vic nez jeden bit, neb interne je presnost 80 (intelovsky FPU). Co se tyce 
tohodle bitu, tak pri dodrzeni podminky ze M je <0.5-1) bude vzdy nejvissy 
bit mantisi 1ka a toho je v IEEE754 zneuzito k tomu (neni pouzivanej a pri 
vypoctech je doplnovanej automaticky) se zvojnasuboje presnost. Pokud se 
dostavas do oblasti nizkych exponentu (hodne malych cisel) tak prestava mit 
smysl neco porovnavat na presnost (ted sa bavime o cislech blizkych 
nejnizsimu vyjadritelnymu cislu). A samozrejmne ze to zavisi na 
zaokrouhlovani (a je jedno jesli je dvojita nebo normlani presnot, vzdy se 
bude zaokrouhlovat). Tedy ano, dovolim si trvdit ze je to spravne (minimalne 
podle IEEE normy kdyz ne podle mne :) 

Podle mne, pokud cisla na vstupu mas presne vyjadritelna v soustave co FPU 
pouziva a vysledek vypoctu je opetovne vyjadritelnej (bez chyb) v soustave 
cisel na vstupu/vustupu (tedy m*10^e), potom ti test bude sedet primo. To jsem 
tim chtel rict. Nic vic nic min. Nechci se prit o zaokrouhlovani a pod. 
To je JINA story. Neboli: 

a=1.345;
b=1.123;
c=a+b;

if (c==2.468) NEBUDE fungovat, protoze 1.123 nevyjadris presne. Bude to
0.5615*2^1 coz je 1.12299999999999999999999999999 [ted uz mne doufam 
nebudes chytat za slovo - mas tu exaktni priklad] coz je sice moooc mala 
chyba (prakticky nevyjadritelna - nekonecne mala - asi jako u tech zlomku 
jak jsem postoval vise), nicmene, zapricini onu 'nepresnost' (kde se porovnava 
absolutni binarni hodnota). Nic vic netvrdim. A proto je epsilon tak maly aby 
pokrylo JEN tento rozdil, NIC vic.

Abych to dokoncil, test neprojde. Pokud a/b zmenis na 

a=1.345
b=1.2228

Tak uz to projde, protoze obe cisla vyjadris presne v notaci FPU

a=0.6725*2^1
b=0.5614*2^1

[oboje jsem pro jistotu odzkousel a fungujou - jak slackware tak windoze]

Zkus si to, pripadne sem muzu nakopirovat binarni podobu techto cisel. Pokud 
bude existovat presna reprezentace mezi soustavama, pak bude i presne sedet 
vysledek. 

Chyba pri vypoctu, vznikla zaokrouhlovanim je 'jina'. Ta se tady neimplikuje 
(kde ce treba ve vyse uvedem projevi ?) Neboli, tuhle chybu ja neberu v potaz, 
protoze uz jen ta "nepresnost" staci k tomu abys potreboval epsilon. A chybu v 
zaokrouhlovani nemuzes posuzovat obecne, ta zalezi uz na konkretni veci (co 
se pocita, jak, v jakym poradi, ....) Ad zaokrouhlovani - tak je to zavisli na 
VYSI cisla, to se shodneme. Ale nepresnot o ktery tu mluvime prameni nekde 
jinde (viz puvodni post kde bylo klasicky a,b,c=a+b a test na c). Nekde muze 
byt chyba (absolutne) 0.0000000000001% 'adekvatni' (a akceptovatelna), jinde 
to mzue byt uplne jinak. 

Nechapu proc sem pletes double a floaty (predpokladam ze mas na mysli 32/64). 
Napis vis co si tim myslel. Ja celou dobu mluvim o nepresnoti jako TAKOVY, ne 
nepresnosti vzikajici PRI vypoctu (opet odkazuji na puvodni post, presne na 
toto narazel). 

 
>  Tohle podle me nezalezi ani tak na soustave, jako spis na lidske definici
> ;) 
Zalezi to na soustave v jaky visla vyjadrujes. Ted nemam na mysli obor 
(N,Z,R,Q...). Pokud jedno cislo vyjadrujes ve tvaru

x=m*10^e
a druhy
y=m*2^e

Tak z toho plyne, ze ne vsechna X bydou mit adekvatni (naprosto __presne__) 
vyjadreni v Y a opacne. Uplne stejne jako barevny soustavy. RGB - HSL - 
CMYK.... Ne vsechny barvy vyjadris presne napric soustavama. Proto ma 
Photoshop a podobny editaci primo (napr.) v CMYK, nebo existujou zobrazovaci 
zarizeni CMYK. Uplne stejne je to s floatama. Pro grafika ta ztrata nekdy muze 
bejt az moc velka. Stejne tak pro matematika. Proto existujou kniohny, ktery 
pocitaj n 'nasi' soustave, tedy nenabalujou se na sebe '2' nepresnoti. 
Nepresnost vypoctu (ta existuje) a neprenost (rekneme) prevodu mezi 
soustavama. 

Nicmene, nejsem matematik tak asi nepouzivam spavne nazvoslovi pro 
soustavu/mnozinu a ja nevim co. Soustava = tak jak cislo vyjadruju (treba 2 
versis 10 v exponentu). Pokud je to jinak, sem s tim.
 

Pivson I a posledni, z bozi vule pivar

    A co budou delat cesi ???
                                     Deme na pivo !