Posted By: pivson (Pijte pivo, je zdrave !!!) on 'CZprogram' Title: Re: Zaokrouhlovani cisla typu Extended Date: Fri May 10 15:10:24 2002 > Hm, jo. Souhlas. Ale nepresnosti nejnizsiho bitu mantisy, ke ktere se pri > "normalnim" zpracovani v pascalu nedostanes. Nebo ano? At tak nebo onak, Nejde jen o neprenost posledniho bitu, ale kdyz mas siclo '5' tak to neni vyjadreno jako '5' a '10^1' v exponentu (binarne). Nejde tedy jen o nejmensi bit, ale o rozdilnou interpretaci. Konkretne (opet IEEE754, Intel) Cislo ma 3 casti: mantisu exponent sign Je jedno jak je co dlouhy (pro 80 bitu je to 64/15/1). Vynecham to, ze nektery kombinace tvori specialni cisla (ala nekonecko, zaporny nekonecne a pod) a ze se ridi podle nastaveni FPU (treba rozklisovani zapornyho a kladnyho nekonecna) a ze nima jdou provadet nektery ukony. Abysme se dostali k jadru veci, v zasade jsou normlizovana a denormalizovana cisla. Normalizovany cislo vypada 'mantisa * 2^exponent' Je to z ciste matematickych duvodu (desitkova soustava je pro pocitani dost nevhodna :o) [tedy vsimni si, neni tu nic o m*10^exp) Napises li tedy 5, nebude to ulozeno jako binarne 0.5 * 10^1 ale jako neco uplne jinyho. __PROTO__ zde vznika urcita nepresnost uz jen vlozenim cisla. Vyjadrim-li se doslova, pak konkretne 5ku FPU _NEDOKAZE_ vyjadrit jako 'absolutni' hodnotu, vzdy se tomu bude 'jen' priblizovat. A to jeste u normalizovanyho cisla je mantisa mezi 0.5-1.0. Je to tedy dost rozdilny od nasich predstav v desitkovy aritmetice. Jen podotykam, ze FPU to dela JEN z duvodu rychlejsiho pocitani. Matematickou teorii okolo toho znam jen trochu (nejsem matematik :o) nicmene, pocitani s cislama v tomto formatu je 'celkem' jednoducha vec [neco jinyho je matika okolo]. Narozdil on formatu, na kterej jsme my zvykli. Je okolo toho fakt docela slusna teorie :o) Jdu se najist a pak dopisu zbytek... > nemuzu proste od sebe odecist dve cisla a porovnat s konstantou, protoze mi > tam porad bude strasit ten exponent, ne? Navic kdyz porovnavam nejaka cisla, > byva to po serii vypoctu, ktere kazdy sam o sobe znamenaji dalsi ztratu > presnosti. Jeste stesti, ze test floatu na rovnost skoro nikdy nepotrebuju a > vystacim si s nerovnostma. Vzpominky na skolu uz se vynoruji tezko :-) Pletes jsem 2 veci... Jedna vec je NEPRESNOST vnikla pri vypoctu (ta se IGNORUJE - je zavisla na konkretnim algoritmu, poradi a ja nevim cem jeste). Nemuzes nadefinvoat 'konstantu' ktera ti rekne 'ted je to jeste dobry'. To jde jedine pro KONKRETNI vec. A pak je tu druha neprest, na kteru jsem poukazoval od zacatku, ale byla vesele ignorovana. A to je NEPRESNOST rozdilnym vyjadrenim cisla. Nebylo, pokud ty napises treba 10000000000000000000000000000000000000000000000.000000000 Tak FPU to bdue interne videt jako 10000000000000000000000000000000000000000000000.0000000001232198536478957345.. Kdyz to reknu jinak, at je cislo VELKY nebo MALI - vzdy se bere ABS(a-b) a to z toho duvodu aby se zjistil ROZDIL. Absolutni rozdil ve vyjadreni techto cisel. Jeli rozdil mensi, nez 'nejmensi krok po kterym je FPU schopny 'korigovat cislo' pak jsou si ty cisla rovny. NE protoze je zde chyba ve FPU a vypoctu, ale protoze FPU vyjadruje cisla JINAK. I integeru CPU ma zakladni jednotku '1'. Muzes napsat 1,2,3... U FPU jsou to sileny mocniny 2. Takze zde neni 'linearni' krok. Proto je jedno, jesli epsilon pouzijes pro MALY/VELKY cislo. Exponent sem VUBEC nemotej, nema s tim NIC spolecnyho. Jo a jeste jedna vec. Narozdil od jinych soustav, u desetinych cisel se presnost vyajdruje NIKOLIV poctem desetinnych mist, ale presnosti 'na zobrazene' cifry. Proto v predhozim pripade (docels slusna presnost mimochodem - drzel jsem tu 0 moc dlouho :o) jsou za 'koncem' cisla dalsi mista. Jasny, nebo je potreba jeste nejakej komentar ? Pivson I a posledni, z bozi vule pivar A co budou delat cesi ??? Deme na pivo !