Hallo,
ich hab gehört, dass man mit BigDecimal und BigInteger viel genauer rechnen kann. Wie kann ich aber diese beiden Typen z.B. miteinander multiplizieren, bzw. aus einem BigInteger einen BigDecimal machen?
Der Compiler mekert immer, dass z.B. multiply nur für BigDecimal vorgesehen ist.
Vielen Dank für eine Antwort
Manny
Moien
ich hab gehört, dass man mit BigDecimal und BigInteger viel
genauer rechnen kann.
Mit BigInteger kann man grössere Zahlen benutzen. Bei Werten unter 2^63 ist „long“ ebenso genau (und viel, viel schneller).
Bigdecimal ist so eine Sache. Korrekt eingesetzt ist es genauer als double. Falsch eingesetzt ist es einfach nur langsam.
Wie kann ich aber diese beiden Typen
z.B. miteinander multiplizieren,
bzw. aus einem BigInteger einen BigDecimal machen?
„BigDecimal.toBigInteger()“ und „new BigDecimal(BigInt)“.
cu
Hi.
Bigdecimal ist so eine Sache. Korrekt eingesetzt ist es
genauer als double. Falsch eingesetzt ist es einfach nur
langsam.
Was muss man denn dabei beachten? Bisher ging ich davon aus, dass BigDecimal automatisch genauer rechnet.
Sebastian.
Moien
Bigdecimal ist so eine Sache. Korrekt eingesetzt ist es
genauer als double. Falsch eingesetzt ist es einfach nur
langsam.Was muss man denn dabei beachten? Bisher ging ich davon aus,
dass BigDecimal automatisch genauer rechnet.
BigDecimal rechnet immer nur mit sovielen Stellen hinterm Komma wie man vorgibt (der Scale-Wert). Man kann durch scale die Genauigkeit auf 0 Nachkommastellen setzen… oder neben auf 2^31 Stellen.
Ein Bigdecimal mit einem scale von 5 ist double bei Werten zwischen 0.000001 und 0.000002 natürlich unterlegen.
Ein Bigdecimal mit scale 2^31 (an sich eine 4 Milliarden Stellen lange BigInteger-Zahl) verbraucht allerdings etwas viel RAM wenn man den Wert 1.1 speichern will (das wird auf 11000000… 2^31-1 x 0 …0000 aufgeblasen)
Vor dem Komma ist das Ding so genau wie man will (solange der RAM und die Geduld des Anwenders reichen). In dem Punkt entspricht das 100% BigInteger.
BigDecimal ist nur für sehr wenige absolute Ausnahmefälle interessant. BigInteger kann ich noch verstehen (Bankkonten) aber bei BigDecimal seh ich nix wo es zwinged nötig wäre.
cu
Hi.
Danke für die Infos.
Sebastian.
Zum Theam Genauigkeit:
Es mag zwar sein, dass long in dem ein oder anderen Fall mehr Stellen darstellt als BigDecimal, genauer ist es aber in keinem Fall.
Arithmetik mit longs ist Gleikommaarithmetik mit den damit verbundenen Schwächen (siehe http://de.wikipedia.org/wiki/Gleitkommazahl).
Rechnungen mit BigDecimal rechnen in der gewünschten Genauigkeit exakt, d.h. 10/3*3 ist wirklich 10 und nicht mur ungefähr 10.
Arithmetik mit longs ist Gleikommaarithmetik mit den damit
verbundenen Schwächen (siehe
http://de.wikipedia.org/wiki/Gleitkommazahl).
Stimmt, und das kann zumindest in wissenschaftlichen, militärischen oder monetären Anwendungen schnell zu Problemen führen. Da kann ich mich nur anschliessen.
Moien
Es mag zwar sein, dass long
(long ist keine Gleitkommazahl. Gleitkomma sind nur double und float)
in dem ein oder anderen Fall mehr
Stellen darstellt als BigDecimal, genauer ist es aber in
keinem Fall.
Wenn du eine BigDecimal mit new BigDemical („5“) anlegt stellt java die scale auf 0 und bleibt dann dabei. Den Wert behält java bei wenn man dividiert (Returns a BigDecimal whose value is (this / val), and whose scale is this.scale()). Teste mal new BigDecimal (1).divide(new BigDecimal (3), IrgendeinRounding).
Macht man zwischendurch setScale (100) sieht die Sache besser aus. Dann kann man double auch schlagen. Nun weiss fast kein Schwein dass es scale überhaupt gibt…
cu