[ Sale_123 @ 11.09.2009. 15:51 ] @
Cesto cujem kako float tip podataka nebi trebao da se koristi u aplikacija koje rade sa novcem, zbog nemogucnosti da se odedjeni decimalni brojevi predstave tacno.

U javi postoji BigDecimal clasa koja taj problem rijesava, a interesuje me kakvo je stanje sa PHP. Da li i dalje koristiti float, koristiti integer pa mnoziti sa 100 da bi se prikazali centi ili postoji neko trece, elegantno rjesenje?

Hvala
[ dakipro @ 11.09.2009. 16:02 ] @
Na sta tacno mislis pod "zbog nemogucnosti da se odedjeni decimalni brojevi predstave tacno." ?
probleme oko zaorkuzivanja ili prikaza?
Uglavnom sam koristio/koristim float, bez ikakvih problema, zaokruzivanje na 2 decimale i toliko.. uglavnom su cene .00 ili .50, pa i kad su .99 nikakav problem, sabiraju se uglavnom, retko dele.
[ Sale_123 @ 11.09.2009. 17:38 ] @
Znam da se ovo sigurno odnosi na C/C++, jer nam je profesor jednom prilikom rekao da je praksa da se u aplikacijama u kojima se barata sa novcem ne koristi float ili double, nego int ili jos bolje long, gdje bi se recimo 2.34 EUR, prestavljalo kao 234. Navodno, ako se koristi float, moze doci do greske prilikom racunanja.

Evo nekih clanaka:

http://www.javaranch.com/journal/2003/07/MoneyInJava.html

http://blog.devspan.com/2007/0...oney-using-floating-point.html

Ovo sto je najzanimljivije sa:
http://us2.php.net/float

Citat:
It is typical that simple decimal fractions like 0.1 or 0.7 cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9.

This is due to the fact that it is impossible to express some fractions in decimal notation with a finite number of digits. For instance, 1/3 in decimal form becomes 0.3.

So never trust floating number results to the last digit, and never compare floating point numbers for equality. If higher precision is necessary, the arbitrary precision math functions and gmp functions are available.


Zelio bih da cujem iskusnije programere sta imaju da kazu o ovome i kakvo je njihovi iskustvo i da li su imali problema ili pogresno izracunatu vrijednost zbog koristenja float-a, jer nebi volio da me neko sutra hvata za vrat zato sto program ne racuna dobro :)

Hvala
[ agvozden @ 11.09.2009. 18:33 ] @
Zavisi kakvu preciznost hoces.
Ako radis trgovinu dovoljan ti je int/100.

Medjutim kod obracuna kamatnih stopa, kamata i planova otplate to nece biti dovoljno.

Radio sam skoro kalkulator za EKS u lizingu.Metoda je slicna vadjenju kvadretnog korena. Bila mi je bitna preciznost od najmanje 6 decimala.
[ BigFoot @ 11.09.2009. 18:49 ] @
Suština zabune je konačnost decimala. Broj 1/3 dobijen na razne načine, iako se uvek dobija 0.333333... kada se uporedi sa istim takvim dobijenim na drugi način, ne mora da se dobije da su isti. Zato se float (i double) uvek porede na odredjeni konačni broj decimala. To je ograničenje zapisa, a ne jezika ili nečeg drugog, ali je i način za rad sa takvim brojevima poznat.
[ Lord_Nenad @ 25.09.2009. 01:06 ] @
Pa ako 1/3 zaokruzis na 6 mesta iza nule dobijes 0.333333 ( umesto 0.333333333333333333333 ) i ako neki drugi nacin izracuna 0.333334 onda to ne moze nikako biti isti broj...

Zaokruzi oba broja prilikom poredjenja, da ne bude poredjenje izmedju 0.333333 i 0.3333333...

Samo nadji koji od ta dva nacina koje uporedjujes ima veci broj decimala i na toj meri "seci", tj "produzi" onaj kome fali



Btw. Ovo je samo moje misljenje, izvinjavam se ako sam nesto pogresno rekao...