[Java] Afronding van een double

[Ryur]

Zo mijn tweede vraag, hopelijk is deze wel goed!

Ik heb hier voor Informatica een Applet moeten schrijven die de de eurobedrag omrekend in dollar en andersom. Het werkt wel, eigenlijk super goed. Alleen nu is de opdracht dat ik (zoals het letterlijk uit het boek komt): "Pas het applet aan zodat bedragen met maximaal twee cijfers achter de komma worden weergegeven". Dus afronding. (Het gaat trouwens om Enigma 4Havo als iemand dat iets zegt)

Ik heb tot nu toe zitten klooien. Ik heb de klasse "import java.math.*;" gebruikt.
En ik heb onderaan bij de code:

Java:

  public void cmdEuroDollarActionPerformed(ActionEvent evt) {
         double eurobedrag = Double.parseDouble(txtEuro.getText());
         double dollarbedrag = Math.round(eurobedrag * 1.48);
         txtDollar.setText(String.valueOf(dollarbedrag));

Zoals jullie zien, gebruik ik wel Math.round, alleen dat rond hij het af op niks. Hoe kan je dan toch gebruiken op 2 decimalen?

[Verwijderd]

Vermenigvuldigen met 100, afronden, delen door 100.

Het is voor geldbedagen overigens beter om met integers te werken, omdat je geen problemen wilt door floating point afwijkingen. Floating point getallen zijn namelijk slechts benaderingen (die in de meeste gevallen wel goed genoeg zijn). Intern werk je liever met geldbedragen in centen, en geef je alleen de komma weer in de output waar hij komen moet.

[Verwijderd]

Math.round() rond af op integers, niet op achter de komma.

toFixed() is volgens mij wat je moet hebben.

*edit* Ik was toch minder wakker dan ik dacht.

[ Voor 11% gewijzigd door Verwijderd op 03-02-2008 12:33 ]

[Verwijderd]

Verwijderd schreef op zondag 03 februari 2008 @ 10:38:
Math.round() rond af op integers, niet op achter de komma.

toFixed() is volgens mij wat je moet hebben.

Java heeft weinig met Javascript te maken. Er zijn overeenkomsten in de syntax, maar verder is het appels met peren vergelijken.

[Ryur]

Verwijderd schreef op zondag 03 februari 2008 @ 10:35:
Vermenigvuldigen met 100, afronden, delen door 100.

Het is voor geldbedagen overigens beter om met integers te werken, omdat je geen problemen wilt door floating point afwijkingen. Floating point getallen zijn namelijk slechts benaderingen (die in de meeste gevallen wel goed genoeg zijn). Intern werk je liever met geldbedragen in centen, en geef je alleen de komma weer in de output waar hij komen moet.

Sorry, maar ik begrijp je uitleg niet zo helemaal. Wel alvast bedankt. Kan jij dan miss een voorbeeld maken met mijn code waarin je je uitleg stopt?

Alvast bedankt!

[brama]

txtDollar.setText(String.format("%.2f", Double.valueOf(dollarbedrag));

oughta do it. String.format() kun je nl. gebruiken om getallen te formatteren zoals jij het wil, via %-notaties. In dit geval betekent '%.2f' dat je een float/double wil afbeelden, waarbij je max 2 getallen achter de komma wil tonen.

[edit]

double dollarbedrag = eurobedrag * 1.48; // is beter dan uiteraard, je wil/moet niets afronden

[edit 2]

Dit mag ook:

code:

txtDollar.setText(String.format("%.2f", dollarbedrag);

Waarom had ik in mijn 1e voorbeeld die Double.valueOf() erin zitten? Omdat ik zag dat die format() methode objecten verwacht als argumenten. Sinds java 1.5 worden integers/doubles/etc (de basis variabele typen) automatisch geconverteerd naar hun object-varianten (Integer, Double classes), waardoor dit niet meer nodig is.

[ Voor 49% gewijzigd door brama op 03-02-2008 11:05 ]

[BastiaanN]

Kijk hier eens:
http://www.leepoint.net/n...onversion/num2string.html

onder het kopje "java.text.DecimalFormat"
Edit: de methode van de vorige poster scheelt je wat code

[ Voor 22% gewijzigd door BastiaanN op 03-02-2008 11:00 ]

[Creepy]

GoTCoast schreef op zondag 03 februari 2008 @ 10:55:
[...]


Sorry, maar ik begrijp je uitleg niet zo helemaal. Wel alvast bedankt. Kan jij dan miss een voorbeeld maken met mijn code waarin je je uitleg stopt?

Alvast bedankt!

Eeh. Vermenigvuldigen met 100, afronden op een geheel getal, en weer delen door 100 zodat je precies 2 cijfers achter de komma kan overhouden. Daar heb je toch geenb code voorbeeld voor nodig lijkt me .

[Jeanpaul145]

GoTCoast schreef op zondag 03 februari 2008 @ 10:55:
[...]


Sorry, maar ik begrijp je uitleg niet zo helemaal. Wel alvast bedankt. Kan jij dan miss een voorbeeld maken met mijn code waarin je je uitleg stopt?

Alvast bedankt!

Waar cheatah zo ongeveer op doelt is (bijvoorbeeld) dit:

Java:

  public void cmdEuroDollarActionPerformed(ActionEvent evt) {
         int euroBedragInCenten = (int)( 100*Double.parseDouble(txtEuro.getText()) );
         int dollarBedragInCentenKeer100 = euroBedragInCenten * 148;
         double dollarbedrag = ( (double) dollarBedragInCentenKeer100 ) / 10000.0; //onthoudt, dat bedrag hierboven is in centen, maar dan nog eens met 100 vermeniguldigd ;)
         txtDollar.setText(String.valueOf(dollarbedrag));

Het kan natuurlijk eleganter (m.n. het casten kan slimmer ) maar goed, dit even ter illustratie van Cheatah's punt .

Het is voor geldbedagen overigens beter om met integers te werken, omdat je geen problemen wilt door floating point afwijkingen.

Nog een reden om met ints te werken: het is sneller

[ Voor 15% gewijzigd door Jeanpaul145 op 03-02-2008 11:17 ]

[brama]

Jeanpaul145 schreef op zondag 03 februari 2008 @ 11:08:
[...]


Waar cheatah zo ongeveer op doelt is (bijvoorbeeld) dit:

Java:

  public void cmdEuroDollarActionPerformed(ActionEvent evt) {
         int euroBedragInCenten = (int)( 100*Double.parseDouble(txtEuro.getText()) );
         int dollarBedragInCentenKeer100 = euroBedragInCenten * 148;
         double dollarbedrag = ( (double) dollarBedragInCentenKeer100 ) / 10000.0; //onthoudt, dat bedrag hierboven is in centen, maar dan nog eens met 100 vermeniguldigd ;)
         txtDollar.setText(String.valueOf(dollarbedrag));

Dan hoor je het bedrag eigenlijk ook niet als een double te parsen, maar direct naar integer. Anders zit je nog te converteren. Maar dat gaat volledig buiten de scope van de opdracht van de poster natuurlijk.

[Voutloos]

Jeanpaul145 schreef op zondag 03 februari 2008 @ 11:08:
Nog een reden om met ints te werken: het is sneller

Slechte reden, kan je maar beter achterwege laten. Geldbedragen wil je in eerste instantie correct hebben, denken over micro optimalisaties kan altijd nog.

[KoW]

Jeanpaul145 schreef op zondag 03 februari 2008 @ 11:08:
Nog een reden om met ints te werken: het is sneller

Nog een reden om het niet te doen:

In je eigen voorbeeld introduceer je een fout van 0,7% door met 148 te vermenigvuldigen.
Dat is de omrekenfactor x 100 afgerond.
Wanneer je dan naar ponden gaat omrekenen kom je met een factor van 75 uit op een fout van meer dan een procent.

Wil je dat?
Wil je niet al je berekeningen zo nauwkeurig mogelijk uitvoeren en alleen op het laatst afronden ?

[Verwijderd]

KoW schreef op zondag 03 februari 2008 @ 12:41:

Wil je niet al je berekeningen zo nauwkeurig mogelijk uitvoeren en alleen op het laatst afronden ?

Wat is nauwkeurig? Een floating point getal heeft per definitie een bepaalde mogelijke afwijking. Als je voor rekenen met geld meer precisie nodig hebt dan centen, dan kan dat ook door nog steeds integers (long) te gebruiken, en dan in gedachten gewoon 4 of 8 cijfers na de komma bijhouden, afhankelijk van wat je precies met de bedragen doet. Maar bij geld is het eerder regel dan uitzondering dat er op centen wordt afgerond, ook als je nog verder mee gaat rekenen.

[LAN]

Als je met geldbedragen werkt kun je ook kijken naar BigDecimal.

BigDecimals hebben het floating-point probleem niet en afronden gaat ook makkelijk:

Java:

BigDecimal origineelBedrag = new BigDecimal("12.1245");
BigDecimal afgerondBedrag = origineelBedrag.setScale(2,BigDecimal.ROUND_HALF_EVEN);
System.out.println(afgerondBedrag.toString());

Geeft: 12.12

[Hydra]

Verwijderd schreef op zondag 03 februari 2008 @ 12:57:
Wat is nauwkeurig? Een floating point getal heeft per definitie een bepaalde mogelijke afwijking.

Ik snap echt niet waar je het idee vandaan haalt dat de precisie van een double een probleem gaat vormen zodat je dan beter met fixed point vars kunt gaan werken

Ja, tuurlijk kun je uiteindelijk afwijkingen krijgen, maar die vallen in het niet bij de fouten je je zelf introduceert door fixed met 2 getallen achter de komma te werken.

[NMe]

Hydra schreef op maandag 04 februari 2008 @ 18:06:
[...]


Ik snap echt niet waar je het idee vandaan haalt dat de precisie van een double een probleem gaat vormen zodat je dan beter met fixed point vars kunt gaan werken

Ik hoop niet dat je ooit een applicatie voor een bank gaat moeten schrijven, want die applicatie gaat duizenden tot miljoenen centen verduisteren zonder dat je dat zo bedoeld hebt. Althans, als je er zo over denkt. [google=floating point round dangers]

[Verwijderd]

Hydra schreef op maandag 04 februari 2008 @ 18:06:

Ik snap echt niet waar je het idee vandaan haalt dat de precisie van een double een probleem gaat vormen zodat je dan beter met fixed point vars kunt gaan werken

Ik snap niet hoe je dit kunt vertellen als je de valkuilen van floating point operations kent. Een floating point getal kun je het best zien als een benadering, en niet als een precies getal.

Ik daag je uit om kloppende berekeningen te maken met (grote) bedragen als floating point getallen, en te bewijzen dat de uitkomst altijd precies juist is, en dat afronding op hele centen nooit een probleem kan zorgen.

Ja, tuurlijk kun je uiteindelijk afwijkingen krijgen, maar die vallen in het niet bij de fouten je je zelf introduceert door fixed met 2 getallen achter de komma te werken.

Soms is dat gedrag juist gewenst, bijvoorbeeld bij belastingaangifte, bij renteberekening en bij het wisselen van valuta. Bij geldzaken is dit zelfs heel vaak gewenst. Floating point operaties kunnen echter afrondingsfouten hebben, rond 8.555 maar eens af.

[Herko_ter_Horst]

Omdat het nog niet expliciet gezegd is: het probleem is niet zozeer het rekenen met decimalen op zich, maar het feit dat niet alle floating point getallen een exacte binaire representatie hebben.

Maar zoals gezegd: in veel gevallen is de afronding alleen een user interface probleem en blijven de onderliggende waardes onafgerond in gebruik (dit om fouten met afronding-op-afronding te voorkomen).

[Verwijderd]

Herko_ter_Horst schreef op maandag 04 februari 2008 @ 19:17:
Omdat het nog niet expliciet gezegd is: het probleem is niet zozeer het rekenen met decimalen op zich, maar het feit dat niet alle floating point getallen een exacte binaire representatie hebben.

Maar zoals gezegd: in veel gevallen is de afronding alleen een user interface probleem en blijven de onderliggende waardes onafgerond in gebruik (dit om fouten met afronding-op-afronding te voorkomen).

Afronding-op-afronding is soms gewenst, zeker bij geldbedragen. Dat heb ik nu al twee keer herhaald.

[Herko_ter_Horst]

Net als met reclame: dat je iets vaak herhaalt wil nog niet zeggen dat het waar is

[Verwijderd]

Herko_ter_Horst schreef op maandag 04 februari 2008 @ 19:41:
Net als met reclame: dat je iets vaak herhaalt wil nog niet zeggen dat het waar is

Heb je weleens belastingaangifte gedaan? Heb je weleens rente ontvangen of betaald? Rente op rente, en dan na jaren erachter komen dat het geldbedrag op je bankrekening elke keer is afgerond, en dat je dus niet een exponentiële functie kunt gebruiken om het exacte bedrag na x jaar te berekenen? Ook al ben ik een man van formules en wetenschap, in de financiële wereld werkt het toch nét even anders.

[Herko_ter_Horst]

Natuurlijk heb ik belastingaangifte gedaan. Wat heeft het feit dat de Belastingdienst alles op hele euro's in het voordeel van de klant afrond met dit probleem te maken?

En als jouw bank je naait door per jaar af te ronden, is dat een probleem tussen die bank en jou. Reken maar dat er tussen banken onderling tot in het oneindige met veel cijfers achter de comma (maar dan met integers) doorgerekend wordt.

[.oisyn]

Hydra schreef op maandag 04 februari 2008 @ 18:06:
[...]


Ik snap echt niet waar je het idee vandaan haalt dat de precisie van een double een probleem gaat vormen zodat je dan beter met fixed point vars kunt gaan werken

De issue is niet floating point versus fixed point. De issue is basis 2 versus basis 10. Floating point is met geldzaken onzinnig omdat je altijd met x cijfers achter de komma werkt - de komma drijft dus niet maar heeft een vaste positie. Dat wil natuurlijk niet zeggen dat het niet kan, je moet zorgen dat je binnen de precisie van je datatype blijft, en dat geldt voor doubles net zo goed als ints.

Echter, zodra je de komma bij een floating point intuitief plaatst (dus 1.0 = 1 euro), krijg je problemen door de basis 2. Een simpel bedrag als 40 cent kun je op die manier bijvoorbeeld al niet precies opslaan in een double. Derhalve, of je nou met floating of met fixed point werkt, gebruik basis 10. Als je in hele centen werkt, vermenigvuldig je dus met 100. En als je dat toch al gaat doen, dan heeft het gebruik van een floating point getal geen voordeel boven een integer (het is alleen extra lastig om de komma drijvende te houden).

Gelukkig ondersteunen veel talen wel gewoon een Decimal type, uitermate geschikt voor geldbedragen, omdat hij de data in basis 10 opslaat.

Ik geloof trouwens dat officieel is vastgelegd dat banken met miljoensten centen werken.

[ Voor 11% gewijzigd door .oisyn op 04-02-2008 20:16 ]

[Verwijderd]

Herko_ter_Horst schreef op maandag 04 februari 2008 @ 20:08:
Natuurlijk heb ik belastingaangifte gedaan. Wat heeft het feit dat de Belastingdienst alles op hele euro's in het voordeel van de klant afrond met dit probleem te maken?

En als jouw bank je naait door per jaar af te ronden, is dat een probleem tussen die bank en jou. Reken maar dat er tussen banken onderling tot in het oneindige met veel cijfers achter de comma (maar dan met integers) doorgerekend wordt.

Tot in het oneindige met veel cijfers achter de komma? Hoeveel cijfers is oneindig dan? En waarom rekenen die banken toch met integers en niet met floating point getallen? Zei ik eerder ook al niet dat je gerust de imaginaire punt best een beetje kunt verplaatsen als dat nodig is, maar dat er wél met integers en vooral niet met floating point getallen gerekend moet worden?

Hoe zit het nou met de volgende som?

Pietje heeft 1000 euro op de bank staan. Hij krijgt van de bak 3,5% rente per jaar. Hoeveel geld heeft Pietje na 10 jaar als hij zijn rekening ongemoeid laat?

Moet je dit oplossen met wiskunde, of moet je dit oplossen met de logica van de mannen van de centen?

Ik word er een beetje moe van dat je suggereert dat ik onzin uitkraam.

Als je met geldbedragen rekent, moet je geen floating point getallen gebruiken. Er is in de financiële wereld vaak een aparte manier van tussendoor bedragen afronden. Dat gaat met floating point getallen niet gegarandeerd goed. Meer is er niet te vertellen.

[MrBucket]

Verwijderd schreef op maandag 04 februari 2008 @ 19:27:
[...]

Afronding-op-afronding is soms gewenst, zeker bij geldbedragen. Dat heb ik nu al twee keer herhaald.

Je haalt twee dingen door elkaar. Dat afronding-op-afronding wordt misbruikt als excuus om minder te hoeven uitbetalen wil nog niet zeggen dat het correct is.

--edit--
Maar ik ben het met je pleidooi eens: gebruik geen floating-point getallen voor geldbedragen.

[ Voor 12% gewijzigd door MrBucket op 04-02-2008 20:40 ]

[.oisyn]

Verwijderd schreef op maandag 04 februari 2008 @ 20:20:
Er is in de financiële wereld vaak een aparte manier van tussendoor bedragen afronden. Dat gaat met floating point getallen niet gegarandeerd goed

Met integers ook niet. Banken implementeren sowieso hun eigen rounding scheme (round-to-even a.k.a. banker's rounding)

[Verwijderd]

.oisyn schreef op maandag 04 februari 2008 @ 21:33:

Met integers ook niet. Banken implementeren sowieso hun eigen rounding scheme (round-to-even a.k.a. banker's rounding)

Dat is niet te implementeren met floating point getallen. Dat er anders wordt afgerond, is nog iets anders dan dat er bij floating point getallen verkeerd kan worden afgerond. Bij het rekenen met integers (dat zijn decimals intern ook, lijkt me) kun je dit wél goed krijgen, zolang je elke keer waar nodig afrondt. En dat gebeurt ook. Je hebt dan in de tussenstappen wel meer precisie nodig, maar die is nog steeds eindig.

Dat round-to-even is er ook slechts om de halve die normaal altijd naar boven zou worden afgerond, in de helft van de gevallen naar beneden af te ronden, omdat er anders langzaam maar zeker een afwijking zou gaan ontstaan in grote aantallen bedragen.

De methode is zinloos op computersystemen, zodra je alsnog gaat rekenen met getallen met een grotere precisie dan waarnaar je wilt afronden.

[.oisyn]

Verwijderd schreef op maandag 04 februari 2008 @ 21:42:
[...]

Dat is niet te implementeren met floating point getallen.

Net zo moeilijk/makkelijk als met integers. Een float is niet heel anders dan een int. Het enige verschil is dat er een exponent bij zit. Die exponent heb je niet nodig, en dat maakt het gebruik van floats onzinnig, zoals ik eerder al zei. Het maakt ze echter niet meer of minder geschikt. Alle waarden van een int passen nog altijd gewoon in een double.

[ Voor 12% gewijzigd door .oisyn op 04-02-2008 21:49 ]

[MrBucket]

.oisyn schreef op maandag 04 februari 2008 @ 21:48:
[...]

Net zo moeilijk/makkelijk als met integers. Een float is niet heel anders dan een int. Het enige verschil is dat er een exponent bij zit. Die exponent heb je niet nodig, en dat maakt het gebruik van floats onzinnig, zoals ik eerder al zei. Het maakt ze echter niet meer of minder geschikt. Alle waarden van een int passen nog altijd gewoon in een double.

Yup, omdat een double 2 keer zoveer geheugen nodig heeft als een int. Wanneer je een long (64 bits, dus ter grootte van een double) zou gebruiken, passen niet alle mogelijke waardes van een long in een double. Zonde van de helft van je geheugen, dus.

Dus waarom zou je floating point getallen gebruiken?

[Verwijderd]

.oisyn schreef op maandag 04 februari 2008 @ 21:48:

Net zo moeilijk/makkelijk als met integers. Een float is niet heel anders dan een int. Het enige verschil is dat er een exponent bij zit. Die exponent heb je niet nodig, en dat maakt het gebruik van floats onzinnig, zoals ik eerder al zei. Het maakt ze echter niet meer of minder geschikt. Alle waarden van een int passen nog altijd gewoon in een double.

Het probleem met floating point getallen is dat de precisie kan verschuiven. In de basis zijn floats en integers natuurlijk gewoon een verzameling bits, waarbij bij floating point getallen nog wat metainformatie is opgeslagen.

Het probleem is echter de manier waarop er met floating point getallen wordt (moet worden) omgegaan. Er wordt vanuit gegaan dat er een bepaalde kleine afwijking mag zijn, en dat maakt floating point berekeningen geschikt voor bijvoorbeeld wetenschappelijke berekening waarbij er altijd al van enige onzekerheid sprake is. Zolang de onzekerheid niet significant toeneemt door floating point berekeningen te gebruiken, is het wetenschappelijk prima te verdedigen, net zoals het prima te verdedigen is om een meetlat te gebruiken die direct of indirect is geijkt aan "de meter" in plaats van de originele "meter" te gebruiken.

Maar dat maakt ze wel ongeschikt voor berekeningen met geldbedragen, omdat je het soort afrondingsfouten van bijvoorbeeld 8.555 niet wilt hebben. Zeker niet omdat de heren van de centen er nogal rare rekenmethodes op na houden.

[.oisyn]

Misschien moet je mijn eerste post in deze draad nog eens doorlezen, want je zit dingen uit te leggen die ik al eerder heb genoemd

je het soort afrondingsfouten van bijvoorbeeld 8.555 niet wilt hebben

Wat ik al zei, dat is een probleem van basis 2. Je kan in feite ook gewoon 8555 in het floating point getal opslaan, dan werkt alles naar wens. Maar dan zet je de komma in principe vast, en daarom is het onzinnig om floating point getallen ervoor te gebruiken. Maar dat maakt ze niet ineens minder geschikt