[IIS / PHP] Fouten in PHP functie round()

[Verwijderd]

Op mijn Windows 2003 server met IIS werkt de functie round() in PHP niet goed. Ik heb het getest op de volgende 2 php versies:

5.2.5 (de nieuwste PHP 5 build)
4.4.8 (de nieuwste PHP 4 build)

De volgende code voer ik uit:

code:

<?
  echo '32.105: ' . round(32.105, 2) . '<br>';  // Geeft 32.1
  echo '31.105: ' . round(31.105, 2);  // Geeft 31.11
?>

Wat blijkt nu? Vanaf 32+ geeft round() onjuiste decimalen terug.

Via google heb ik geprobeerd te achterhalen wat dit probleem kan zijn, maar wat ik erover terugvindt helpt me nergens mee.

[Jorik90]

Deze fout (niet specifiek voor Windows) wordt ook aangekaart bij de reacties op functie round op php.net. Misschien kun je wat met deze reacties, hier te vinden.

[TheBorg]

Zie ook:
http://www.php.net/manual/en/language.types.float.php

[TeeDee]

Ik denk dat je gewoon niet moet vertrouwen op round. Pak dan integers en pas het aan in je presentatie.

[/laat]

[ Voor 5% gewijzigd door TeeDee op 04-02-2008 16:13 ]

[Verwijderd]

Het probleem is dat het hier om een systeem gaat waar al zeer veel data in staat, en dat de round functie in ontzettend veel verschillende pagina's/regels aangeroepen wordt.

Ik heb de links bekeken waar naar verwezen wordt in bovenstaande reacties, maar hier staat volgens mij niet veel over het betreffende probleem.

[ Voor 3% gewijzigd door Verwijderd op 05-02-2008 11:21 ]

[serkoon]

Dit is gewoon een effect van het gebruik van floating point (zie de link eerder in het topic). Python geeft bijvoorbeeld:

code:

>>> a=32.105
>>> b=31.105
>>> round(a,2)
32.100000000000001
>>> round(b,2)
31.109999999999999

Floating point is nu eenmaal niet zo precies als in je software blijkbaar is aangenomen.

[elevator]

Dit heeft niets met servers te maken, maar inderdaad met het feit dat floating point getallen soms (als het ware) een benadering zijn van het getal dat ze moeten voorstellen.

Deze discussie hoort meer op z'n plek in Programming, ik verplaats je topic dan ook daar naar toe

Windows Servers en Server-software >> Programming

[Xcalibur]

elevator schreef op maandag 04 februari 2008 @ 23:24:
Dit heeft niets met servers te maken, maar inderdaad met het feit dat floating point getallen soms (als het ware) een benadering zijn van het getal dat ze moeten voorstellen.

Zou je dit kunnen toelichten?

Het afronden van een getal lijkt me toch een redelijk eenvoudig principe, waarbij het resultaat altijd te voorspellen is. Waarom kan een computer dat dan niet, die zijn toch goed met cijfertjes?

[sopsop]

Xcalibur schreef op dinsdag 05 februari 2008 @ 08:52:
[...]


Zou je dit kunnen toelichten?

Het afronden van een getal lijkt me toch een redelijk eenvoudig principe, waarbij het resultaat altijd te voorspellen is. Waarom kan een computer dat dan niet, die zijn toch goed met cijfertjes?

De computer kan dit wel, je moet alleen correcte datatypes gebruiken. In dit geval dus geen floating.

[ChessSpider]

Inderdaad... Het getal * 100 doen dus en daar dan de berekeningen op los laten

[Janoz]

Xcalibur schreef op dinsdag 05 februari 2008 @ 08:52:
[...]


Zou je dit kunnen toelichten?

Het afronden van een getal lijkt me toch een redelijk eenvoudig principe, waarbij het resultaat altijd te voorspellen is. Waarom kan een computer dat dan niet, die zijn toch goed met cijfertjes?

Computers zijn perfect met cijfertjes en het gedrag is ook keurig voorspelbaar. Probleem is echter dat computers met het binaire talstelsel werken. Niet elke waarde is in elk talstelsel uit te drukken. Neem bijvoorbeeld 1/3. Dit is niet op te schrijven met het decimale stelsel. Bij het binaire stelsel geld zoiets bijvoorbeeld voor 0.1.

Dit alles is ook keurig beschreven in veel artikellen over floating point getallen.

[Verwijderd]

ChessSpider schreef op dinsdag 05 februari 2008 @ 09:01:
Inderdaad... Het getal * 100 doen dus en daar dan de berekeningen op los laten

Ik was er zelf inderdaad ook achtergekomen dat dit een oplossing voor het probleem is.

Maar ik vind het nog steeds lastig te begrijpen dat dit zo ongelooflijk slecht werkt. Waarom kan de round() functie zelf niet verzinnen dat je het juiste antwoord wil hebben (en dus eventueel x 100 of x groter getal doen) ?

[ChessSpider]

Verwijderd schreef op dinsdag 05 februari 2008 @ 09:46:
[...]


Ik was er zelf inderdaad ook achtergekomen dat dit een oplossing voor het probleem is.

Maar ik vind het nog steeds lastig te begrijpen dat dit zo ongelooflijk slecht werkt. Waarom kan de round() functie zelf niet verzinnen dat je het juiste antwoord wil hebben (en dus eventueel x 100 of x groter getal doen) ?

Volgens mij heb je bij 64bits systemen een veel hogere preciesie. Sowieso zal je nog wel een keer tegen de limieten van een integer aanlopen; bijvoorbeeld bij het verkrijgen van de bestandsgrootte van een bestand groter dan 2GB (unsigned int) of 4gb (signed int). Dat is iets waar ik de afgelopen tijd tegenaan liep..

Btw niks belet jou die functie te maken . Maar de meeste mensen willen niet dat een functie voor hen gaat denken.

[RobIII]

Euh, ik ben niet bekend met PHP maar heeft het niets te maken met Banker's rounding / Round-to-even?
Hmmm, volgens een quick-peek in de docs/comments toch niet.

[ Voor 15% gewijzigd door RobIII op 05-02-2008 10:04 ]

[FragFrog]

Verwijderd schreef op dinsdag 05 februari 2008 @ 09:46:
Maar ik vind het nog steeds lastig te begrijpen dat dit zo ongelooflijk slecht werkt. Waarom kan de round() functie zelf niet verzinnen dat je het juiste antwoord wil hebben (en dus eventueel x 100 of x groter getal doen) ?

Floats zijn nu eenmaal een geweldige manier om zowel hele kleine getallen als hele grote getallen binnen dezelfde hoeveelheid bytes uit te drukken. Dat komt met een prijs, namelijk dat je getal altijd een benadering is van de daadwerkelijke waarde. Daar merk je meestal weinig van, tot je dergelijke functies gaat gebruiken; het voorbeeld van serkoon is hier een mooie illustratie bij.

Als dat niet uitmaakt is er weinig aan de hand, als dat wel uitmaakt moet je geen float gebruiken

* FragFrog heeft zijn collega's heel hard lopen schoppen toen ze floats wilden gebruiken voor betalingsinformatie

[ Voor 7% gewijzigd door FragFrog op 05-02-2008 10:15 ]

[Verwijderd]

FragFrog schreef op dinsdag 05 februari 2008 @ 10:14:
[...]

Floats zijn nu eenmaal een geweldige manier om zowel hele kleine getallen als hele grote getallen binnen dezelfde hoeveelheid bytes uit te drukken. Dat komt met een prijs, namelijk dat je getal altijd een benadering is van de daadwerkelijke waarde. Daar merk je meestal weinig van, tot je dergelijke functies gaat gebruiken; het voorbeeld van serkoon is hier een mooie illustratie bij.

Als dat niet uitmaakt is er weinig aan de hand, als dat wel uitmaakt moet je geen float gebruiken

* FragFrog heeft zijn collega's heel hard lopen schoppen toen ze floats wilden gebruiken voor betalingsinformatie

Dat is dus het probleem ook in dit geval. Het gaat om een erg groot administratiesysteem waarin alle bedragen opgeslagen worden als floats.

code:

function trueRound($input, $dec) {
  $input = $input + 0.000001;
  return round ($input, $dec);
}

Bovenstaande functie lijkt mijn probleem op te lossen. Ik heb veel getallen getest, en het lijkt altijd goed uit te komen. Iemand die bezwaar ziet in het gebruiken hiervan ?

[ Voor 6% gewijzigd door Verwijderd op 05-02-2008 10:25 ]

[Janoz]

Je functie is een quickfix die heel toevallig in deze situatie een gewenst resultaat oplevert. In andere situaties gaat het juist voor meer problemen zorgen. Ten eerste is het helemaal niet gegarandeerd dat er altijd foutief naar beneden afgerond wordt. Het kan ook dat er juist naar boven afgerond wordt en dat effect wordt juist alleen maar versterkt door deze functie. Daarnaast is de keuze voor 10^-x erg onhandig omdat dit juist zo'n waarde is die niet weer te geven is in het binaire stelsel.

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:52 ]

[Verwijderd]

era.zer schreef op dinsdag 05 februari 2008 @ 10:55:

code:

$eenfloat = 32.105;
echo $eenfloat;

geeft dat 32.105 ?
Ik weet dat floats anders worden opgeslaan dan 32.105 exact meestal, maar normaal geeft PHP toch in bovenstaande code als ouput 32.105 en niet 32.10499999999999 ?

Zo ja, maak gewoon een function stringRound()
convert de float naar een string en zoek dan zelf de punt en tot waar je significantie wil en zelf het laatste cijfertje bepalen. (zoals een mens het dus doet)

Hmm dit klinkt inderdaad als de makkelijkste en beste oplossing. Bedankt voor je reactie.

Toch zou het leuk zijn als PHP bijv. door een php instelling zelf dit soort dingen ook kan doen met de functie round().

[ Voor 8% gewijzigd door Verwijderd op 05-02-2008 11:20 ]

[Janoz]

Vlaataap, lees de reacties eens. Dit is helemaal geen probleem van php of zomaar met een instelling te verbeteren. Dit is een inherent gevolg van het gebruik van het floating point datatype. Iedere professional zal daarom ook afraden om een float type te gebruiken in software waar met bedragen gerekend wordt.

De beste oplossing is om decimals te gebruiken, maar dat type bestaat niet in php. Het is daarom ook beter om met fixed point getallen te werken.

[Verwijderd]

Janoz schreef op dinsdag 05 februari 2008 @ 11:23:
Vlaataap, lees de reacties eens. Dit is helemaal geen probleem van php of zomaar met een instelling te verbeteren. Dit is een inherent gevolg van het gebruik van het floating point datatype. Iedere professional zal daarom ook afraden om een float type te gebruiken in software waar met bedragen gerekend wordt.

De beste oplossing is om decimals te gebruiken, maar dat type bestaat niet in php. Het is daarom ook beter om met fixed point getallen te werken.

Ik heb de reacties (aandachtig) gelezen. Ik ben dan ook bezig mijn systeem om te zetten naar integers.

Maar wat ik niet begrijp: in welke situatie levert het voordeel op dat PHP niet zelf deze 'afwijking' (zal ik het maar noemen, ook al is het logisch) corrigeert.

[Cloud]

Verwijderd schreef op dinsdag 05 februari 2008 @ 11:24:
Maar wat ik niet begrijp: in welke situatie levert het voordeel op dat PHP niet zelf deze 'afwijking' (zal ik het maar noemen, ook al is het logisch) corrigeert.

PHP kán de afwijking niet corrigeren, omdat deze niet constant hetzelfde is. PHP zelf maakt geen fout, het is puur inherent aan het gebruik van floats, ongeacht de taal.

Toevallig was er gister ook een topic wat precies over hetzelfde probleem gaat, maar dan in een andere taal. Kijk eens hier: [Java] Afronding van een double

En vooral de link die hier verschaft wordt, geeft veel gedetailleerde uitleg over het probleem.

[ Voor 12% gewijzigd door Cloud op 05-02-2008 11:29 ]

[Janoz]

Het punt is dat php dit zelf helemaal niet kan corrigeren. Hij weet namelijk helemaal niet dat het 31.105 was.

Als ik 1/3 op sla in een decimaal veld met 2 cijfers achter de komma wordt dat 0,33. Maar vanaf dat moment weet ik immers ook niet meer welke waarde tussen 0,325 en 0,335 het nu eigenlijk was. En of 3x die waarde nu 0,975 of 1,05 is.

[Verwijderd]

Wat ook kan,
$getal = 32.105 + 0.005 ;
sprintf("%.2f", $getal);

0.005 optellen en dan afkappen staat gelijk aan afronden op 2 decimalen.

[Voutloos]

Wat nog steeds een hack is. Ipv hack op hack op hack te bouwen om een symptoom van een probleem weg te werken, kan je beter gewoon de oorzaak aanpakken.

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:52 ]

[Cloud]

era.zer schreef op dinsdag 05 februari 2008 @ 14:15:
De TS zijn code wordt bij mij (linux bak PHP 5.2.4) wel correct uitgevoerd, dus ligt het niet zozeer aan floats maar meer aan Windows of de configuratie.

Heb je de gegeven links en reacties überhaupt wel gelezen? Dit is een probleem van floating points dat altijd aanwezig is, ongeacht de taal én ongeacht de omgeving. Met Windows heeft het niets te maken.

Lees deze google hits en dit wikipedia artikel nog eens

[ Voor 8% gewijzigd door Cloud op 05-02-2008 14:26 ]

[apokalypse]

wolkje schreef op dinsdag 05 februari 2008 @ 14:25:
[...]

Heb je de gegeven links en reacties überhaupt wel gelezen? Dit is een probleem van floating points dat altijd aanwezig is, ongeacht de taal én ongeacht de omgeving. Met Windows heeft het niets te maken.

Lees deze google hits en dit wikipedia artikel nog eens

Zover ik weet wordt PHP omgezet naar C, en is C toch echt wel afhankelijk van je systeem. Maar ok.
Het probleem zal wel op ieder systeem zijn, maar waar de grens ligt verschilt per systeem.

[ Voor 6% gewijzigd door apokalypse op 05-02-2008 14:31 ]

[? ?]

..

[ Voor 117% gewijzigd door ? ? op 25-01-2013 09:52 ]

[TeeDee]

era.zer schreef op dinsdag 05 februari 2008 @ 14:15:
....

Deze specifieke floats misschien wel, hell, in c# heb ik het ook getest en daar kreeg ik ook 'de goede' resultaten. Voor deze floats wel. Verderop krijg je alsnog (mogelijk) foute waardes. Alleen is het niet te zeggen waar.

[Cloud]

apokalypse schreef op dinsdag 05 februari 2008 @ 14:30:
Zover ik weet wordt PHP omgezet naar C, en is C toch echt wel afhankelijk van je systeem. Maar ok.

Tenzij C floating points op een andere manier opslaat dan de specificatie voorschrijft, heeft dat er niets mee te maken.

Het probleem zal wel op ieder systeem zijn, maar waar de grens ligt verschilt per systeem.

Er is niet echt een grens te definiëren. Floating point afwijkingen komen op elk systeem voor, maar niet noodzakelijk altijd op dezelfde momenten. De afwijking kan zelfs per keer verschillen ook al is de bedoelde waarde hetzelfde.

era.zer schreef op dinsdag 05 februari 2008 @ 14:31:
euhm, waarom doet hij het bij mij wel goed?

Zie boven.

het is niet omdat het een float is dat het gegarandeerd mis gaat en in dit geval zou het moeten werken

Het is omdat het een float is, dat het fout kan gaan. Ik heb nooit gegarandeerd gezegd. En het is dus niet zo dat het 'in dit geval zou moeten werken', want dat weet je dus niet zeker. Zoals je bij de TS wel ziet dus.

Mensen lees nu eens de achterliggende principes zodat je weet wáárom het fout kan gaan.

edit:
Ik heb ook in verscheidene talen, omgevingen en systemen de fouten gezien in floating points. Als het niet fout mag gaan gebruik ik decimals (in C# althans).
Voor valuta is het ook mogelijk om alles in centen uit te drukken en met integers te gaan rekenen.

[ Voor 9% gewijzigd door Cloud op 05-02-2008 15:17 ]

[FragFrog]

wolkje schreef op dinsdag 05 februari 2008 @ 15:15:
Ik heb ook in verscheidene talen, omgevingen en systemen de fouten gezien in floating points. Als het niet fout mag gaan gebruik ik decimals (in C# althans).
Voor valuta is het ook mogelijk om alles in centen uit te drukken en met integers te gaan rekenen.

Enige juiste oplossing eigenlijk. Ik heb vrij moeilijke colleges numerieke wiskunde gehad over hoe je kan zorgen dat wetenschappelijke berekeningen zo min mogelijk afrondingsfouten bevatten, vuistregel is eigenlijk dat als je echt precisie wilt je heel goed na moet denken over je berekening en het dan nog vaak beter kan

Enkel centen is trouwens ook niet altijd voldoende, als je daarmee gaat rekenen kun je alsnog afrondingsfouten krijgen. Valutadiensten rekenen niet zelden met 5 tot zelfs 12 decimalen om die reden

[? ?]

..

[ Voor 100% gewijzigd door ? ? op 25-01-2013 09:52 ]

[Voutloos]

Heb je wellicht gelijk in, allemaal leuk en aardig, maar als je dat geleerd hebt weet je gewoon dat niet alles 1 op 1 als float opgeslagen kan worden en dat je dus niet altijd met floats wil werken. Klaor.

Imo is het vrij schrikbarend/teleurstellend hoeveel mensen de basiskennis over hoe een float werkt missen.

[? ?]

..

[ Voor 103% gewijzigd door ? ? op 25-01-2013 09:52 ]

[FragFrog]

era.zer schreef op dinsdag 05 februari 2008 @ 16:17:
Als dat opgelost is, zal de TS zijn code niet moeten veranderen, het zal werken zoals voorheen

Als dat opgelost is werkt de TS nog steeds met floats om valutainformatie op te slaan. Dat is bijna altijd zo'n slecht plan dat'ie alsnog beter zijn code kan veranderen

//edit
Overigens zou het zomaar kunnen zijn dat de ene machine 64 bit floats gebruikt en de andere 32 bit; in zoverre kan het van je OS afhangen waar je onnauwkeurigheden gaat zien. Veel heb je niet aan die informatie though

[ Voor 23% gewijzigd door FragFrog op 05-02-2008 16:49 ]

[Voutloos]

era.zer schreef op dinsdag 05 februari 2008 @ 16:17:
Dus question remains: why the hell is het op zijn Windows box anders dan op mijn default Linux box
Als dat opgelost is, zal de TS zijn code niet moeten veranderen, het zal werken zoals voorheen

Nee, dan ziet hoe toevallig bij deze waarden het symptoom niet. Het is juist een zegen (!) dat je nu die fout ziet, want dan kan je het probleem aanpakken.

[TeeDee]

era.zer schreef op dinsdag 05 februari 2008 @ 16:17:
^{Ja tuurlijk, een float is niet precies...}
Dus question remains: why the hell is het op zijn Windows box anders dan op mijn default Linux box
Als dat opgelost is, zal de TS zijn code niet moeten veranderen, het zal werken zoals voorheen

Misschien het verschil in gebruik van compilers?

[Hydra]

Volgens mij heeft dat weinig te maken met afwijkingen die je krijgt en meer met dat er een bug in de round functie zit, of dat de implementatie van floats onder PHP gewoon brak is. Onder .net werkt die afronding wel prima. Bij een dergelijk beperkt aantal significante getallen is een float ruim voldoende.

Edit: 'prima' in de zin dat er aan beide kanten 31.1 uitkomt.

[ Voor 9% gewijzigd door Hydra op 05-02-2008 18:02 ]