Jeste, ali --- zar to nije očekivano ponašanje pri radu sa floating-point brojevima?

Ako otvoriš VS i kreneš

double a = 6.0;
double b = -0.2;

a += b; Console.WriteLine( a );
a += b; Console.WriteLine( a );
a += b; Console.WriteLine( a );
...

Dobićeš isto ponašanje.

To je i razlog zašto se floating-point brojevi ne porede tipa if ( a==b ) već se uvek uzima u obzir tražena tačnost..

Tačno tako. Float brojevi se ponašaju drugačije. Znam, kad programiram, da moram oduzimati 2 float broja, pa ako im je apsolutna razlika manja od npr. 0.00001, onda su ta 2 broja jednaka itd...

Kod float brojeva nema a==b!

Takođe, kod sukcesivnog oduzimanja greška se sve više povećava. Zato je u numeričkoj matematici uobičajena praksa da se umesto (na prvi pogled) zdravorazumskog
a_n = a_n-1 + delta
koristi
a_n = a₀ + n * delta
zbog smanjenja greške.

nice try

da da.. ali pricamo o excellu... ako ima u jednacini brojeve napisane na jedno mesto, reda 10^(-1), i rezultat koji ima prvih 15 mesta '0', onda bi morao da napise '0'. Ako bi ovu racunicu upotrebljavali recimo sa 'starim' dinarima, pomnozili to sa cenom recimo hleba od nekoliko stotina milijardi i jos sa nekoliko milijona ljudi, dobili bi neke stvarno cudne brojke za 'nulu'...

U tom slučaju možeš da uključiš (isključiš) opciju "Precision as Displayed".

Mogu samo da potvrde da je cova koji je "otkrio" bag informaticki nepismen.

Floating point brojevi funkcionisu tako od kada su izmisljeni.

Cekaj, zasto je :

4 - 0.2 = 3.8 a ne 9.19,5T-32 ? naprimer ?????

Nesto se ne secam da sam u nekoj knjizi o Excelu mogao da procitam o floating "problemtici"
A sumnjam da na kursevima o Windows/Office u delu posvecenom excelu pomiinje negde "floating" termin
Da zamislim kolegu koji nesto racuna i pomaze koleginici i onda teatralno kaze:E nemoj to, tu ma kvaka sa "floating"
Kako vas bre ne smara da serete ovoliko?
5 godina koristim excel i prvi put cuujem za to.
Ili je Excel takodje postao aplikakcija za iskusne programere?

Citam onu temu sa unistavanjem diska od strane linuxa, i tu se smarate do bola a onda odvalite ovakvu glupost tipa:
Ma daj ne tupi, to je floating, ne znas VB, majmune jedan

Serete bre

0.2 - 0.2 = 0

Nula

N U L A

Pa to i jeste 0 u Excelu ;-)

A sad lepo, pre nego sto krenes u optuzivanje drugih da "seru" procitaj sta pise u uputstvu za reprodukciju 'baga':



Dakle, ni u Excel-u se to ne vidi dok IEEE754 round-off error ne postane dovoljno bitan da utice na prikaz.

IEEE754 round-off error nije bag - to je osobina floating point brojeva. A kome to ne odgovara moze da:

1. Koristi fixed-point brojeve

ili



Dakle, sod-off, trolovi.



Excel pojma nema sta ti radis sa tim brojevima - on samo postuje IEEE standard. Postoji opcija, koju je degojs naveo, koja radi to sto zelis, ali ne moze biti "default" jer se ne zna cemu te kalkulacije sluze i da li je ta mala vrednost "round off error" ili je pak nesto sto sluzi necemu.

@str-es

Brojevi u pokretnom zarezu se matematicki gledano pamte u obliku , gde je , neki ceo broj (opseg je ogranicen),a broj koji nije manji od nule, a manji je od . U principu nije manji ni od ali moze da bude ako je broj blizak nuli (preciznije, ako uzima najmanju vrednost iz dozvoljenog opsega) i tada se zove subnormalnim jer se belezi manji broj znacajnih binarnih cifara, ali se u racunu ponasa kao najobicniji realan broj. No, broj se belezi sa fisknim brojem binarnih cifara, koji zavisi od tipa podatka koji se koristi (u jezicima C/C++ float, double ili long double) i to je ono sto je ovde od esencijalne vaznosti. Dakle,

Brojevi u pokretnom zarezu se beleze sa konacnim brojem binarnih cifara.

E, sad, posto niti jedan potpun stepen broja (dakle, broj poput ) nije deljiv sa 10, u opstem slucaju konverzija iz dekadnog zapisa u binarni se ne moze obaviti tacno, vec samo priblizno. Preciznije, postoje brojevi koji u dekadnom sistemu imaju konacan zapis, a u binarnom sistemu beskonacan zapis. Takav je recimo broj 0.1 koji u dkadnom sistemu ocigledno ima konacan zapis, ali u binarnom ima beskonacan periodicni zapis koji glasi



Iz tog razloga se broj 0.1 ne moze prikazati tacno nijednim sistemom zasnovanim na zapisima konacnog broja binarnih cifara, vec samo priblizno. Kada u jeziku C++ napises nesto poput

promenljiva x ce dobiti vrednost koja je priblizno jednaka 0.1, ali joj nije jednaka. Medjutim, na ekranu ce biti prikazan broj 0.1 jer se ispis vrsi na svga nekoliko decimala, pa je odstupanje dovoljno malo da se prilikom konverzije u dekadni brojni sistem (u kome ce broj biti prikazan na ekranu) vrsi zaokruzivanje na 0.1.

Medjutim, broj 10 je deljiv brojem 2, pa svaki broj koji ima konacan binarni zapis ima i konacan dekadni zapis. Zaista, ako neki broj ima konacan binarni zapis, on mora biti oblika



za neki ceo broj i prirodan broj . Medjutim, tada je

,

pa svakako ima i konacan dekadni zapis. Za razliku od toga, broj se ne moze prikazati u obliku jer koliko god puta ga mnozio dvojkom, neces pokratiti onu desetku dole i dobiti ceo broj.
Stoga je obrnuta konverzija (iz binarnog sistema u dekadni) u principu moguca, pa se moze prikazati na ekranu u dekadnom sistemu sta je tacno racunar zapamtio.

Matematicki, da bi "izvukao" dekadne cifre iz broja x koji ima konacan binarni zapis, trebao bi da izvrsis sledecu proceduru

Medjutim, ni tada neces dobiti tacan rezultat (bar ne u opstem slucaju) jer ova procedura koristi racunske operacije (kao sto je mnozenje sa 10) koje se takodje obavljaju samo priblizno u racunaru. Stoga se procedura koja ispisuje tacno u dekadnom sistemu sta je tacno zapamceno u promenljivoj tipa float, double ili long double mora pisati daleko pazljivije.

Ako te zanima sta se tacno dobija u promenljivama tih tipova kada pokusas da smestis u njih jedinicu, pa izvrsis delenje sa 10, evo, za tebe sam izracunao tacne vrednosti memorisanih brojeva:



Na kraju, zasto je 0.2-0.2=0. Pa zato sto, bez obzira sto je reprezentacija broja 0.2 u memoriji racunara samo priblizna, ona je (u istom tipu) uvek ista, pa kada istu velicinu (kakva god da je) oduzmes od iste, svakako da treba da dobijes nulu.

_{[Ovu poruku je menjao Nedeljko dana 23.07.2008. u 11:16 GMT+1]}

Odluke tipa if (a<b) { ... } else { ... } mogu itekako (ponekad) da imaju smisla, ali tu treba biti vrlo oprezan. Naime, mora se biti siguran da ce u slucaju bliskih vrednosti a i b ulazenje u pogresnu granu proizvodi finalni rezultat (koji korisnika interesuje) biti priblizno tacan, a ne besmislen. Cak i if (a==0) {... } else { ... } moze imati smisla ako treba izbeci neko delenje nulom itd., mada je u tom slucaju situacija daleko slozenija (isfinite(), isnan(),...). Vazno je voditi racuna o koncepciji algoritma tako da se bude siguran da program ne bi zveknuo, zaglavio ili proizveo besmislen rezultat.



Ovo je obicno najjednostavnije smisleno resenje ovog problema, ali ne i najbolje.

Ivane,

Nemoj se čuditi zašto članovi kao što je str-es ovaka reaguju kada ih provociraš. Pogledaj kakve izraze upotrebljavaš.



Ako neko nešto ne zna, a ti si stručnjak za to, onda mu lepo izađi u susret i objasni mu. Tako treba da se ponaša stručnjak, a ne da zezaš ljude zato što nešto ne znaju. I ti ponekad pišeš o stvarima koje ne znaš, pa šta.

Oni su u pravu da tako nešto ne moraju da znaju korisnici excela. No, dobro. Excel izbacuje rezultate koji su približno tačni onoliko koliko to omogućavaju IEEE754 standardi i koliko su dobro podržani. A tačno je i da u udžbenicima excel-a ne piše (mada nisam nikada čitao nijedan) ni da je SQRT(2) samo približno jednako . Treba li to da zna svaki korisnik excela? Ne mora. Postoji velika razlika između približno tačnog i besmislenog rezultata. Ako neko baš zapne sa ovakvim pitanjem, treba mu odgovoriti i to je sve.

Mnogo "produktivniji" način nagomilavanja greške je računanje članova Fibonačijevog niza sa nekim početnim uslovima tipa 0.2, 0.3. Greška raste eksponencijalnom brzinom.

Naravno da je ovo bug. Slazem se sa str-es potpuno:)
Ne znam sta se desava kod Open-Office-ovog Calc-a, da li je ista stvar.

Ukoliko postoje problemi u radu sa float brojevima, ono sto se prikazuje korisniku
kao vrednost u nekoj celiji prosto mora biti tacno (znaci ako se videlo da se greska javlja,
treba je korigovati da se prikazuje tacan rezultat, a ne objasnjavati netacne
rezultate nacinima na koje racunar vrsi racunske operacije. To zaista korisnika ne zanima)

Hajde leba ti, napiši mi u pozicionom dekadnom sistemu tačan rezultat delenja 1 sa 3 ili tačnu vrednost primene operacije kvadratnog korena na broj 2. Razumem ja korisnika, ali ako on očekuje nemoguće, to je njegov lični problem, a ne problem softvera.

Ako se korisniku ne sviđa što excel prikazuje netačne rezultate, slobodno može da uzme neki drugi program, koji takođe prikazuje netačne rezultate. To je pravo kupca na izbor proizvoda, koje niko ne osporava, ali to nema veze sa kvalitetom softverskog proizvoda.

Ali bi moglo da ima veze sa gubitkom nekog ko posluje a oslanja se na Excel
i njegove rezultate, zar ne? :)

MS Excel - potencijalno unistava vas novcanik :)

Koliko i svaki drugi program te vrste.

I šta ćemo sad?

Nista, otvoriti novu temu o tome da Open-Office Calc ima isti bug ;)

Salu na stranu, jel moguce ove greske detektovati i ispraviti?
Recimo ako je jasno da ce izvestan broj odredjenih operacija sigurno
dovesti do greske - unapred predvideti i nekako ispraviti?

Jer nije mi jasno da se ne moze programski detektovati i resiti da 1,2 - 0,2 nije 0,9999999997.... nego je 1?

Pa kad krenem da oduzimam po 0.2 od 6 i u windows kalkulatoru, pa ni on ne pravi ovakve greske...

Nije. O tome se i radi. Uvek ces dobijati samo priblizne rezultate.



Lepo sam te pitao da mi napises tacan rezultat delenja 1 sa 3 ili tacan rezultat korenovanja broja 2. Kad budes malo porazmislio o tome, videces da je tacan rezultat nemoguce prikazati sta god radio.



Sve sto ti nije jasno je posledica necitanja prethodnih poruka, posebno mojih u kojima sam detaljno sve objasnio.



Ali pravi druge. Sta kaze, koliko je 1/3 ili .?

Može, ali po cenu jezivog usporenja proračuna, reda veličine 100-1000; da se i ne spominju moguće greške u izvedbi. Ima gde je tačna realna aritmetika dovoljno potrebna da opravda ovo — u tabelarcima to svakako nije.

Moze da resi taj problem (i slicni problemi sa mnozenjem, sabiranjem i oduzimanjem brojeva koji u dekadnom zapisu imaju konacan zapis) ako se koristi predstavljanje brojeva u pozicionom sistemu sa osnovom b deljivom sa 10. Medjutim, problemi delenja i korenovanja se ne mogu resiti ako rezultati moraju biti prikazani u pozicionom sistemu.

Naravno da nije bug, jer Excel postuje IEEE754 floating point standard kao sto treba da ga postuje gde je round-off error neizbezan.

Nedeljko ti je objasnio ZASTO sa floating point brojevima ne mozes da dobijes to sto zelis.

A, kao sto vidis, i drugi programi imaju istu "gresku".

Sta cemo sad? Dobar je ovaj Advocacy, BillG je izgleda kriv i za fundamentalne matematicke probleme ;-)

Da zakljucimo - Excel nema bagova a 1,2 minus 0,2 je jednako: 0.0000000000079234.

Znaci, papir i olovku u ruke... pa polako :)

Eto,

I kako, @Nedeljko, ne smejati se ovakvom ociglednom nepoznavanju materije, ovo je tako slashdotovski ;-)

@Kernel-1, dobrodosao u svet floating pointa koji je takav kakav je, mozda ce te to naterati da bacis sve svoje kompjutere i kupis olovku i papirce, posto tesko da ce i jedan floating-point racun da zadovolji tvoje potrebe za preciznoscu.

Mozes da se zalis IEEE-u, njihovi inzenjeri nemaju pojma, treba da konsultuju Slashdot oko FPU aritmetike.

Izmedju ostalog, okrivicemo Billa Gates-a za to, a isti takav "bag" u Open Office-u se moze opravdati kompromisom Open Source komune koja je primorana da se povinuje bagovima koje je Bill Gates uveo u racunarski svet.



Moj Excel kaze da je 1 - ali je tvoj citat dovoljan za prihvatanje za top post na Slashdotu, ima odlican "M$ bashing" ratio bez obzira na ocigledan nedostatak supstance, ili zdravog razuma ;-)

Koliko znam, ovo nije ni softverski, već hardverski "bag" (FPU je sastavni deo mikroprocesora), tako da nijansu različit rezultat može da se dobije eventualno promenom procesora, a ne softvera (od BIOS-a i operativnog sistema, pa nadalje).

Roundoff error je inherentni problem floating point reprezentacije i moze se samo smanjiti, ali ne i potpuno ukloniti jer bi za njegovo uklanjanje bio potreban beskonacan broj bitova za skladistenje broja, sto svakako nije prakticno.

Menjanjem hardvera se nece promeniti fakat da on uvek postoji - razlike u round-off greski izmedju raznih procesora su zbog razlicitog internog formata floating point brojeva koje procesori koriste (Intel-ovi procesori koriste 80-bitni floating point format za FPU tj. x87 operacije).

32-bitni IEEE754 floating point ima veci round-off error od 64-bitnog IEEE754 double formata, dok interna reprezentacija u Intel procesorima ima 80-bita a postoji i vise nacina ophodjenja sa tom greskom - odatle dolazi do razlicitih rezultata.

http://en.wikipedia.org/wiki/Machine_epsilon

Shvatio sam zasto dolazi do greske posle objasnjenja o problematici kod takve prirode operacija,
ali greska se javlja - to je poenta. I nigde ja nisam branio ni na koji nacin OpenOffice, samo sam
pitao da li se ista greska javlja i tamo (bilo mi je logicno da se javlja ako se radi o istoj problematici).

Ivane,

ne vidim zašto meni sve to pričaš. Misliš li da ja to ne znam? Pa, hajde onda da odgovorim i ja tebi.



Nije nepraktično, već je nemoguće. Kada bi bilo moguće, bilo bi vrlo praktično.



To nije jedini izvor razlika. Prvo, čovek realne brojeve unosi (uglavnom) u dekadnom sistemu (bilo da to čini krajnji korisnik preko polja za unos ili da ih programer ukucava u izvorni kod programa). Tu dolazi do konverzije iz dekadnog sistema u binarni. Ne samo da je iz razloga koje sam naveo u svojoj prvoj poruci to u opštem slučaju nemoguće učiniti tačno, već se ni tačnost koju korišćeni tip podataka dopušta ne mora dostići, jer softver vrši konverziju korišćenjem računskih operacija u pokretnom zarezu, koje takođe proizvode grešku, tako da se mogu očekivati i razlike u rezultatu izvršavanju programa kompajliranog različitim kompajlerima.

Takođe, matematičke funkcije kao što je se u FPU izračunavaju po numeričkim algoritmima koji nisu isti kod svih proizvođača, pa se mogu očekivati razlike u izračunatoj vrednosti za .

@Nedeljko,

Slazem se sa tim sto si napisao - i razlozi koje si ti naveo (dekadna->binarna konverzija) isto ucestvuju u povecavanju greske.



Da. Greska se javlja, ali to nije bug kako si ti naveo i optuzio "excel", posto je ta greska sastavni i neizbezni deo floating point aritmetike.

Excel tu ne radi nista pogresno, bas kao ni OpenOffice.

@Kernel-1

Evo, izračunao sam kako teče izračunavanje sa početka teme u 32-bitnom 64-bitnom i 80-bitnom tipu realnih brojeva:

Na kraju krajeva, nije mi jasno zašto ovi homosi iz MS-a i Sun-a ne koriste long double kao tip podataka u aplikacijama, nego double. Ne kažem da je razlika velika, ali ipak.

Evo kako izgleda broj 0.2 u tri realna tipa:

Verovatno zbog potpune kompatibilnosti sa ranijim formatima / formulama koje vec imaju znanje o tome da je u pitanju 64-bitni double, a ne long double. Ranije je verovatno ta odluka doneta zbog performansi.

To (kompatibilnost) je obicno vise bitno nego malo veca preciznost koja bi se dobila sa long double formatom. Kako Excel a ni OpenOffice Calc nisu naucni programi, od njih se i ne ocekuje da podrzavaju takvu preciznost.

Inače je čitava nauka pročitati double i konvertovati ga u long double.

Prilikom sumiranja više sabiraka dolazi do dodatne greške, koja se nagomilava u procesu sumiranja. Postoje algoritmi sumiranja kod kojih ne dolazi do te dodatne greške. Jedan od takvih je Shewchuk-ov algoritam implementiran ovde kao prva python funkcija. Taj algoritam je implementiran u pythonovoj standardnoj biblioteci kao math.fsum funkcija.

Naravno ovo



je samo optička varka, jer kada se doda -1 kao prvi sabirak, dobija se



U drugom slučaju imamo samo grešku konverzije iz dekadnog sistema u binarni (do na to se vrši full precision sabiranje, tj. dobija se najbliži predstavljiv broj tačnoj sumi, koja je u našem slučaju 0), a u prvom i algoritam sumiranja u pokretnom zarezu pravi svoju grešku. Dakle, ima algoritama različite numeričke stabilnosti, ali su neke vrste grešaka neminovne (konverzija iz dekadnog sistema u binarni i nemogućnost smeštanja u FP tip onoliko bitova koliko ih ima tačan rezultat).

Ova funkcija na primeru koji priložen za excel daje manju grešku, ali je daje, jer je već pri pretvaranju iz dekadnog sistema u binarni došlo do neke greške.