[PHP] Vermenigvuldigen met 2 cijfers achter komma

[Verwijderd]

Hey,

Ik heb het volgende probleem, ik wil dat bij het vermenigvuldigen van de prijs van het artikel en het aantal dat deze persoon heeft besteld dat de uitkomst ook met cijfers achter de komma werkt.

Dit is de code die ik gebruik:

PHP:

echo '<td>€'.$OrderItem['Prijs'] * $OrderItem['Aant'].'</td>';

waarbij de prijs 39,99 is en het aantal bijvoorbeeld 11

Ik krijg dus nu 429 euro ipv 439,89... nogal een groot verschil dus.

Hoe kan ik het zo krijgen dat ik 2 cijfers achter de komma krijg? en dat dit dan ook in de berekening goed gaat?

Alvast bedankt!

[Kippenijzer]

Waarschijnlijk werkt het wel met '.' ipv ',' als decimal separator. Zijn verschillende opties voor om dat op te lossen, makkelijkst (maar zeker niet netste) is gewoon 'number_format' gebruiken, maar zie de php manual voor de nettere oplossingen

[Haan]

Wat je zou kunnen doen is eerst de prijs x 100 doen en na de vermenigvuldiging het result weer / 100.
Dan krijg je dus (3999 x 11) / 100 = 439, 89

(als je programma er tenminste geen 439 van maakt..)

[ Voor 15% gewijzigd door Haan op 22-10-2007 15:00 ]

[mithras]

Rekenen met floating points zal zorgen dat het altijd wel goed gaat. Geen string pakken met komma's maar floating points zal al een stuk helpen. In php is het dus met een punt:

PHP:

$price = 39.99;
$number = 11;
$result = $price * $number;
echo $result;

[Bitage]

Je zou haakjes er omheen kunnen zetten, dus

code:

echo '<td>€'.($OrderItem['Prijs'] * $OrderItem['Aant']).'</td>';

Voor de rest, zijn beide decimalen gescheiden van de helen dmv een punt (.) en niet met een komma (,)?

Edit: denk eigenlijk wel zeker dat de komma je de das omdoet. 39 * 11 = 429

[ Voor 14% gewijzigd door Bitage op 22-10-2007 15:04 ]

[cenix]

Is het scheidingsteken correct? Dus een punt ipv een komma of andersom, zoals eerder aangegeven.
Wat is $OrderItem, iets uit een database? Wat is het type van dit veld. Hoe haal je deze gegevens uit de db?

[Ivo]

Voor geldbedragern zou ik alles met integer waarden berekenen. Bij het weergeven kun je dan een float pakken waarin je de integer waarde gedeeld door 100 zet. Dan heb je in je berekeningen oneindige precisie zo lang je binnen de range van je datatype blijft.

[Verwijderd]

inderdaad.. heb nu eens een . gebruikt ipv een , en dan gaat het perfect...

[Grijze Vos]

Ivo schreef op maandag 22 oktober 2007 @ 15:18:
Voor geldbedragern zou ik alles met integer waarden berekenen. Bij het weergeven kun je dan een float pakken waarin je de integer waarde gedeeld door 100 zet. Dan heb je in je berekeningen oneindige precisie zo lang je binnen de range van je datatype blijft.

Daar ben ik het mee eens, da's het makkelijkste.

[Verwijderd]

Ivo schreef op maandag 22 oktober 2007 @ 15:18:
Voor geldbedragern zou ik alles met integer waarden berekenen. Bij het weergeven kun je dan een float pakken waarin je de integer waarde gedeeld door 100 zet. Dan heb je in je berekeningen oneindige precisie zo lang je binnen de range van je datatype blijft.

Waarom dat dan weer? Waarom zou je met floats geen precisie hebben?

[Janoz]

@Wriker: Vanwege de afrond problemen die inherent zijn aan het floating point datatype.

[Cartman!]

Raad je echt aan om prijzen voor producten dan ook als integer op te slaan ipv float met 2 achter de komma (bijv. 10,2) ?

[Johnny]

Cartman! schreef op maandag 22 oktober 2007 @ 15:51:
Raad je echt aan om prijzen voor producten dan ook als integer op te slaan ipv float met 2 achter de komma (bijv. 10,2) ?

Ja. Voor geldbedragen is het altijd het handigst om gewoon met het de kleinste eenheid, in dit geval eurocenten te werken en alleen het bedrag enkel in euro's weer te geven.

[mithras]

Waarom niet gewoon een floating point gebruiken? Je hebt een onnauwkeurigheid, maar die loopt in de één-miljoensten. Bedragen, zeker in dit geval, zullen tot hondersten berekend worden (namelijk centen), dus de onnauwkeurigheid zal nooit met je bedrag interfereren oftewel het verschil (floating point - daadwerkelijk bedrag) << epsilon.

[ Voor 6% gewijzigd door mithras op 22-10-2007 15:57 ]

[DataGhost]

Afgezien van de minieme afwijking neemt een float meer ruimte in dan een int. Als het 4 vs 8 bytes is bespaar je op grote tabellen al gauw heel veel. Geldbedragen die buiten 32 bits (in centen) lopen heb ik nog niet zo vaak gezien in standaardsituaties, maar als je met zulke bedragen zou werken neem ik aan dat dit topic ook niet nodig geweest was.

Verder is een fixed-point waarde intuitief een stuk juister, aangezien je een fixed aantal decimalen hebt. Floating-point is daarom gewoon overkill Het zit allemaal al in de naam.

[ Voor 21% gewijzigd door DataGhost op 22-10-2007 18:40 ]

[.oisyn]

Ivo schreef op maandag 22 oktober 2007 @ 15:18:
Voor geldbedragern zou ik alles met integer waarden berekenen. Bij het weergeven kun je dan een float pakken waarin je de integer waarde gedeeld door 100 zet. Dan heb je in je berekeningen oneindige precisie zo lang je binnen de range van je datatype blijft.

Contradictio in terminis . "Zolang je in de range van het datatype blijft" => "oneindige precisie". Het eerste impliceert natuurlijk dat je juist geen oneindige precisie hebt, en bovendien kun je dat net zo goed toepassen op float. Je kunt prima floats gebruiken, zolang je binnen het bereik van floats blijft. 0.01 ligt helaas niet binnen een bereik van floats, en dus is het idd niet handig om geldbedragen in drijvendekommagetallen uit te drukken, maar juist met vastekommagetallen (in basis-10).

Overigens hebben floats in PHP over het algemeen een grotere precisie dan een int (53 bits tov 32 bits)

mithras schreef op maandag 22 oktober 2007 @ 15:56:
Waarom niet gewoon een floating point gebruiken? Je hebt een onnauwkeurigheid, maar die loopt in de één-miljoensten. Bedragen, zeker in dit geval, zullen tot hondersten berekend worden (namelijk centen), dus de onnauwkeurigheid zal nooit met je bedrag interfereren oftewel het verschil (floating point - daadwerkelijk bedrag) << epsilon.

Om precies te zijn, 0.01 ~= 0.01000000000000000020816681711721685132943093776702880859375. Maar vergis je daar niet in. Als je 50 jaar rente-op-rente gaat rekenen met een startbedrag van 10.000 euro en een rentepercentage van 4%, dan kom je al 3,3 cent te laag uit.

[ Voor 26% gewijzigd door .oisyn op 23-10-2007 00:32 ]

[Johnny]

Daar komt nog bij dat je ook voor floats een functie nodig hebt om ze correct weer te geven omdat je in plaats van '2.6' de prijs als '2,60' wilt zien.

Ook voorkom je dat er illegale waarden in je database terecht komen zoals 2.605 wat bij berekeningen afwijkingen kan gaan opleveren die exponentieel groter kunnen worden. Zo zal het bij een afronding 2.61 opleveren, maar zal het 2.60 worden als je enkel de laatste twee getallen achter de punt pakt (bijvoorbeeld met de functie number_format).

[ Voor 13% gewijzigd door Johnny op 23-10-2007 00:30 ]

[RobIII]

.oisyn schreef op dinsdag 23 oktober 2007 @ 00:12:
Maar vergis je daar niet in. Als je 50 jaar rente-op-rente gaat rekenen met een startbedrag van 10.000 euro en een rentepercentage van 4%, dan kom je al 3,3 cent te laag uit.

Of erger

Johnny schreef op dinsdag 23 oktober 2007 @ 00:27:
Ook voorkom je dat er illegale waarden in je database terecht komen zoals 2.605 wat bij berekeningen afwijkingen kan gaan opleveren die exponentieel groter kunnen worden. Zo zal het bij een afronding 2.61 opleveren, maar zal het 2.60 worden als je enkel de laatste twee getallen achter de punt pakt (bijvoorbeeld met de functie number_format).

Als je met bedragen werkt, gebruik dan gewoon de decimal/currency/money typen waar beschikbaar (en toereikend).

[ Voor 46% gewijzigd door RobIII op 23-10-2007 00:48 ]