Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

PHP, novac, i preciznost - potencijalni problemi?

[es] :: PHP :: PHP, novac, i preciznost - potencijalni problemi?

[ Pregleda: 2186 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Sale_123
C++ Developer
Wien

Član broj: 23293
Poruke: 219
*.teol.net.



+120 Profil

icon PHP, novac, i preciznost - potencijalni problemi?11.09.2009. u 15:51 - pre 177 meseci
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
...
 
Odgovor na temu

dakipro
Dalibor Jovic
Web Developer
Bergen, Norway

Moderator
Član broj: 31848
Poruke: 1792
*.adsl.beotel.net.

Sajt: norway.dakipro.com


+190 Profil

icon Re: PHP, novac, i preciznost - potencijalni problemi?11.09.2009. u 16:02 - pre 177 meseci
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.
 
Odgovor na temu

Sale_123
C++ Developer
Wien

Član broj: 23293
Poruke: 219
*.teol.net.



+120 Profil

icon Re: PHP, novac, i preciznost - potencijalni problemi?11.09.2009. u 17:38 - pre 177 meseci
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
...
 
Odgovor na temu

agvozden
Aleksandar Gvozden
founder
Info-G
Beograd

Član broj: 37813
Poruke: 1122
93.86.99.*

Sajt: www.gvozden.info


+68 Profil

icon Re: PHP, novac, i preciznost - potencijalni problemi?11.09.2009. u 18:33 - pre 177 meseci
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.

 
Odgovor na temu

BigFoot
Boban Jovanović
Arilje

Član broj: 1098
Poruke: 991
91.150.111.*



+35 Profil

icon Re: PHP, novac, i preciznost - potencijalni problemi?11.09.2009. u 18:49 - pre 177 meseci
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.
Two beer or not two beer...
 
Odgovor na temu

Lord_Nenad
Lord_Nenad
Zvornik

Član broj: 143541
Poruke: 170
*.net.



+8 Profil

icon Re: PHP, novac, i preciznost - potencijalni problemi?25.09.2009. u 01:06 - pre 176 meseci
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...
 
Odgovor na temu

[es] :: PHP :: PHP, novac, i preciznost - potencijalni problemi?

[ Pregleda: 2186 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.