[PHP] Złe zaokrąglanie, Funkcja round() wyczynia cuda. Opcje

[msulik]

Witam. Nie siedzę w bugach php ani innych takich wynalazkach, więc może robię wiele hałasu o nic.

Mianowicie mamy sobie liczbę netto * vat = brutto, tzn 371.311475 * 1.22 = 452.9999995 (szesc dziewiatek i piątka). Zaokrąglenie do 6 miejsc po przecinku powinno dac 453. I tak sie prawie dzieje:

[PHP] pobierz, plaintext 
<?php
echo round(452.9999995, 6); // Daje 453
 
// Ale juz np.
echo round(371.311475 * 1.22, 6);
// powinno dawac teoretycznie to samo, czyz nie?
 
// Czesciowe rozwiazanie tego problemu, to dodanie 001 na koncu liczby netto:
echo round(371.311475001 * 1.22, 6); // i teraz jest ok - daje 453
?>
[PHP] pobierz, plaintext 

Podobny problem z tymi zerami na koncu mam w MySQL:

[SQL] pobierz, plaintext 
SELECT round(371.311475 * 1.22, 6), round(371.311475000001 * 1.22, 6)
[SQL] pobierz, plaintext 

To daje nam:
452.999999 | 453

Na chlopski rozum to bez sensu. W szkole uczyli mnie, że jak się zaokrągla do N miejsc po przecinku, to patrzy się nie dalej jak N+1.

Czy ktos moze mi to wyjasnic jak pastuch krowie?

[Seth]

Wyglada na to, ze to nie jest blad php:

http://binarychoice.pl/_images/vs_round.gif

[NuLL]

Hehe - to tak zawsze jest z VAT-em.

[Marusz]

No dobra... ale co powiecie na to:

[PHP] pobierz, plaintext 
<?php
 
$vA = 452.9999995;
$vB = 371.311475;
$vV = 1.22;
 
$vZ = $vB*$vV;
 
echo $vA . "n";
echo $vZ . "n";
 
if ( $vA == $vZ )
{
 
	echo "OKn";
 
}
else 
{
 
	echo "AMOKn";
 
}
 
?>
[PHP] pobierz, plaintext 

Output:

452.9999995
452.9999995
AMOK

Ten post edytował Marusz 26.08.2005, 00:24:57

[NuLL]

A czy liczby porównywane zgadzają się binarnie Bo tu mogą być ucięte.

[dr_bonzo]

Pewnie jest to zwiazane ze sposobem przechowywania liczb przez php

[PHP] pobierz, plaintext 
<?php
print( round( round(371.311475 * 1.22, 7), 6 ) . '<br />' );
?>
[PHP] pobierz, plaintext 

^^^Wydaje sie dzialac.

[NuLL]

Pewnie tak

Gdyby wykorzystać funkcje kalkulatora binarnego wyniki byłyby dobre.

[popo]

liczby rzeczywiste sa przechowywane (nie tylko w php) jako cecha i mantysa co w polaczeniu z ograniczona dlugoscia slowa binarnego (zalezne od jezyka i procesora) powstaja bledy zaokraglen i nie jest to wada php tylko tego ze komputery pracuja w systemie binarnym o ograniczonej precyzji obliczen jesli moge cos zasugerowac to przy liczbach z okreslonego przedzialu mozna zapisywac je w bazie jako staloprzecinkowe typ DECIMAL powinno toto nieco polepszyc sytuacje co do php to

Precyzja liczb zmiennoprzecinkowych

Jest oczywiste, że nawet proste ułamki dziesiętne, takie jak 0.1 lub 0.7, nie mogą zostać skonwertowane na ich dwójkowe odpowiedniki bez niewielkiej straty dokładności. Może to powodować pewne problemy: na przykład wyrażenie floor((0.1+0.7)*10) zwykle ma wartość 7, zamiast oczekiwanej 8, gdyż wewnętrzna reprezentacja tego wartości to liczba 7.9999999999....

Powiązane jest to z faktem, że dla pewnych ułamków zwykłych nie istnieje skończone rozwinięcie dziesiętne. Na przykład 1/3 w reprezentacji dziesiętnej ma wartość 0.3333333. . ..

Dlatego nigdy nie należy wierzyć liczbom zmiennoprzecinkowym do ostatniej cyfry i nigdy nie należy wykonywać operacji porównania na stwierdzenie równości. Do operacji na liczbach zmiennoprzecinkowych o naprawdę dużej precyzji należy użyć biblioteki BCMath lub funkcji gmp.

cytat z manuala
http://php.net.pl/manual/pl/language.types...float-precision

[TomASS]

Zgadza się, komputer (a właściwie system) przetrzymuje liczby zmiennoprzecinkowe (i nie tylko) jako pewne, bardzo dokładne (ale zawsze niedokładne ) PRZYBLIŻENIE i z tąd mogą pochodzić te błędy.