# BigInteger-Problem



## MPW (11. Dez 2006)

Hallo,

ich möchte gerne die aufgabe hier (Einsendedatum schon abgelaufen...ihr braucht euch also keine moralischen Vorwürfe zu machen, wenn ihr mir helfts)  mal nur so zum Spaß mit Java lösen.

Kurze Zusammenfassung der Aufgabe:

Es soll (2^10)^64 gelöst werden, und die *Anzahl der Stellen* bestimmt werden, die diese Zahl hat.

Ich habe mir dazu follgendes überlegt:


```
import java.math.BigInteger;


public class BigCalculator {
	private BigInteger basis = BigInteger.valueOf(1024);
	private BigInteger ergebnis;
	
	public BigCalculator() {
		ergebnis = basis.pow(64);
		System.out.println(ergebnis.toString());
		System.out.println();
		System.out.println(ergebnis.bitLength());
	}
	public static void main(String[] args) {
		new BigCalculator();
	}

}
```

erzeugt:

```
456244061762219521864117160570029132489322850724855993057919251789927/51672086773865059128113173713997786423095735944073106/
88704721375437998252661319722214188251994674360264950082874192246603776

641
```
 // /=von mir gemachter Umbruch zur Formatierung


2^10 ist ja 1024, das benutze ich direkt als Startwert.

Beim Exponenzieren baut Java leider nur noch Mist, die Zahl ist viel zu klein und die Stellenanzahl stimmt vorne und hinten nicht.

Frage: Kann BitInteger mit dieser Größe an Zahlen rechnen? Warum funktioniert das nicht, warum rechnet er falsch/bzw. gibt bei toString() nicht die richtige Zahl aus?(sie ist viel zu kurz, daher weiß ich, dass sie falasch ist.
[Liegt es vllt. an einer Limitierung von String?]

kann ich mit bitLength() die Anz. der Stellen bestimmen, oder muss ich das anders machen?

Danke für Antworten


----------



## Wildcard (11. Dez 2006)

MPW hat gesagt.:
			
		

> Beim Exponenzieren baut Java leider nur noch Mist, die Zahl ist viel zu klein und die Stellenanzahl stimmt vorne und hinten nicht.


Nicht java baut Mist, sondern du  :roll: 
Das Ergebnis ist korrekt, aber bitLength gibt dir eben *nicht* die Anzahl an Dezimalstellen zurück.
Wer lesen kann ist klar im Vorteil...


----------



## MPW (11. Dez 2006)

Hm, ich habe leider die englische Beschreibung in der Api nicht genau verstanden? Wie kann ich denn die Länge bestimmen?

Mir ist auch aufgefallen, dass ich die Umgruppierung von 2^(10^64) zu (2^10)^64 garnicht machen darf.

Ich werd das nochmal überarbeiten und mich dann melden.

Wie kann ich denn allgemein gesagt, die Länge eines BigIntegers bestimen?


----------



## Wildcard (11. Dez 2006)

Am einfachsten geht das wohl mit einem String.


----------



## MPW (11. Dez 2006)

Ah okay, d.h. ein String ist also nicht limitiert und ich kann beliebig große Zahlen "nach String exportieren" und String.length() aufrufen?  - Danke!


----------



## byte (11. Dez 2006)

Ein String wird intern als Char-Array abgebildet und ist daher beschränkt auf Integer.MAX_VALUE Zeichen.


----------



## MPW (12. Dez 2006)

Hm, dann geht das so nicht....ich fürchte, dass auch das der Grund ist, warum die Zahl im BigInteger zu klein ist.

Gibt es irgendwelche Packages die mit noch größeren Zahlen rechnen können? Nur so spaßeshalber, dass man die Lösung auch anders berechnen kann, ist mir klar.


----------



## SnooP (12. Dez 2006)

hmm... was kommt denn für ne Länge raus? Wenn man 1024 potenziert, wird bei jedem Mal die Länge um drei Stellen vergrößert, oder nicht? ... bei ^64 demnach 63*3 = 189 Stellen + die vier Stellen der 1024 macht 193 Stellen die rauskommen sollten (zeigt übrigens auch der windows-taschenrechner an).

Da Integer.MAX_VALUE weit davon entfernt ist, kannst du mit length locker die Länge der Zahl bestimmen...

BigInteger ist das Maximale mit was man inJ ava so rechnen kann... viel mehr ist auch in anderen Sprachen sicher nicht möglich, weil man irgendwann immer an Speichergrenzen stoßen wird... - und wenn es nur Speichergrenzen zur Indexierung z.B. eines Arrays sind.

Interessant wird das ganze übrigens dann, wenn man das ohne BigInteger programmiert  ... z.B. in Form von Listen, in Arrays oder mit binären Tricksereien und Fast-Exponentation...

edit: nachdem ich mir dann nochmal alles durchgelesen hab - und die Original-Aufgabenstellung gesichtet hab, hab ich dann doch gesehen, dass du eigentlich eher 2^(10^64) lösen wolltest. Was natürlich ein ganz anderer Schuh ist... ich vermute mal, dass da BigInteger auch nicht mehr mit hinkommt und du solltest das ganze über die Logarithmen lösen, wie in der Lösung angegeben... - damit sollte auch mit Java die richtige Stellenanzahl zu berechnen sein.


----------



## MPW (12. Dez 2006)

Genau das ist das Problem, habe ich oben falsch geschrieben.

Mit Logarithmen kann man es natürlich lösen, aber ich dachte halt, man könnte es mal mit BigInteger versuchen...schade eigentlich.


----------



## Leroy42 (12. Dez 2006)

SnooP hat gesagt.:
			
		

> edit: nachdem ich mir dann nochmal alles durchgelesen hab - und die Original-Aufgabenstellung gesichtet hab, hab ich dann doch gesehen, dass du eigentlich eher 2^(10^64) lösen wolltest. Was natürlich ein ganz anderer Schuh ist... *ich vermute mal*, dass da BigInteger auch nicht mehr mit hinkommt



 :shock: Ach Jungs!

2^(10^64) sind in reiner Bitdarstellung 10^64 Bits.
Also 10^61 Bytes= 10 Dezillionen Bytes.

Ein Computer, der _beinahe_ soviele Bits speichern kann, wie
es Atome im Universum gibt, läßt mit Sicherheit noch eine
Zeitlang auf sich warten.  :autsch:


----------



## 0xdeadbeef (12. Dez 2006)

Also falls es noch darum geht...

Mein Calcutta sagt:
(2**10)**64 = 4.5624406176221952e+192   

Also 193 Stellen bzw. voll ausgeschrieben:
4562440617622195218641171605700291324893228507248559930579192517899275167208677386505912811317371399778642309573594407310688704721375437998252661319722214188251994674360264950082874192246603776


----------



## Leroy42 (12. Dez 2006)

Hallo? Jemand zu Hause??  :shock:   

In der Originalaufgabenstellung steht 2^(10^64) und das ist doch schon
ziemlich anders als (2^10)^64 = 2^640


----------



## MPW (12. Dez 2006)

Jo okay, Thema wird beerdigt


----------

