[Java] double afrondingsprobleem

Pagina: 1
Acties:

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Ik zit met een vaag probleem omtrent de berekening van een aantal double values.
Voor een bepaalde berekening, die uitgevoerd wordt, kan een gebruiker een aantal waarden opgeven die de berekening kan beïnvloeden (zoals bvb 'aantal'). Ook kunnen er overige kosten rechtstreeks ingegeven worden. Hier werd het probleem opgemerkt.

Bij een ingave van:
code:
1
2
3
4
64.11 wordt 64.11
64.12 wordt 64.13
...
64.17 wordt 64.18

worden de resultaten dus foutief berekend. Dit is natuurlijk een vrij lastig probleem, aangezien het hier over bedragen en prijzen gaat.

Natuurlijk weet ik dat double/float benaderingen zijn en dus 64.18 intern gerepresenteerd kan worden als 64.179999..

Ik zou dit probleem echter wel op een deftige manier willen oplossen. Wat is een goede manier om dit probleem af te wenden?

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:42
Decimal gebruiken.

Java zal toch wel een decimal type hebben ? Als het gaat om prijzen / aantallen, iets waarvoor de preciezie van belang is, moet je decimal gebruiken.

[ Voor 81% gewijzigd door whoami op 18-01-2006 12:57 ]

https://fgheysels.github.io/


  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Java heeft inderdaad een BigDecimal (j2se.1.4.2 api - BigDecimal). Maar dan zal ik overal mijn double's naar BigDecimal moeten aanpassen en om de persistentie naar de database door te voeren, dien ik deze dan te converteren naar String?

Het eigenaardige is, dat de inputbox waar de kost ingegeven wordt, na de berekening wél nog gewoon correct weergegeven wordt.

  • Confusion
  • Registratie: April 2001
  • Laatst online: 01-03-2024

Confusion

Fallen from grace

-FoX- schreef op woensdag 18 januari 2006 @ 12:52:
Natuurlijk weet ik dat double/float benaderingen zijn en dus 64.18 intern gerepresenteerd kan worden als 64.179999..
De afrondingsfout in je eindantwoord is van de orde 1 op 1000. De fouten door representatie van je doubles zijn veel kleiner. Waar in je berekening blaas je die fout op? Want daar moet je het probleem aanpakken en bijvoorbeeld tijdelijk op integers overstappen ter representatie van het hele getal. In principe doet java.math.BigDecimal dat voor je, maar het slim aanpassen van de volgorde van berekening kan genoeg zijn. Eerst vermenigvuldigen en daarna pas delen is bijvoorbeeld iets dat al de oplossing kan zijn.

[ Voor 11% gewijzigd door Confusion op 18-01-2006 13:26 ]

Wie trösten wir uns, die Mörder aller Mörder?


  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Blijkbaar is het probleem opgelost door volgende regel:
Java:
1
new BigDecimal(other).setScale(2, BigDecimal.ROUND_UP).doubleValue();

te wijzigen in:
Java:
1
new BigDecimal(other).setScale(2, BigDecimal.ROUND_HALF_UP).doubleValue();

[ Voor 3% gewijzigd door -FoX- op 18-01-2006 13:41 ]