Ich hab mal versucht die FibonacciFolge in C++ iterativ auszudrücken.
Allerdings kommt es, dass sie ab der 47. Stelle eine negative Zahl herauskommt. Dabei addiert der Code doch nur 2 positive Zahlen, wie kann da eine negative Zahl herauskommen?!
Der Witz ist auch, dass sie anscheinend bis zu46. Stelle noch stimmt.
Der Code ist wohl richtig aber es findet an der Stelle ein Überlauf statt, da das Ergebnis ein int ist. d.h. das höchstwertige Bit ist zuständig für das Vorzeichen und ab der Stelle, wo die erste negative Zahl vorkommt, wird das höchstwertige Bit auf 1 gesetzt und somit ist die Zahl negativ
Der Code ist wohl richtig aber es findet an der Stelle ein Überlauf statt, da das Ergebnis ein int ist. d.h. das höchstwertige Bit ist zuständig für das Vorzeichen und ab der Stelle, wo die erste negative Zahl vorkommt, wird das höchstwertige Bit auf 1 gesetzt und somit ist die Zahl negativ
...
Das heißt ich sollte long statt int verwenden?
EDIT:
Meh. Das funktioniert leider auch nicht.
/edit: long ist in 32Bit Systemen genauso groß wie ein int nämlich 32Bit.
...
Hab aber 64 Bit^^
Und mit long long funktioniert es Oo
Mit unsigned int auch
EDIT:
Nein, mit unsigned int geht es auch nur bis zur 48ten. Dann kommt wieder eine kleiner Zahl, die nicht in die Folge passt.
Also bräuchte ich nur ein usigned long oder (unsigned) long long
Okay, hab das Problem jetzt verstanden, es liegt am Variablentyp^^
mmh, ich glaub, du solltest dich mal mit Bits, Bytes und vorallem mit den Datentypen von C auseinandersetzen.
2 ^ 64 Bits wären 2 Zebibyte (wenn ich richtig gerechnet habe). Also eine Speichergröße enormer Ausmaßen, die wir wohl in unseren Lebzeiten nie erreichen werden ... denke ich aber Bill Gates hat sich ja auch mal enorm verschätzt ^^
Wir sind momentan bei etwa 16 GiB RAM für Serversysteme, das sind, wenn ich mich jetzt im Kopf nicht verrechnet habe, 2^37 Bit. Nach dem Mooreschen Gesetz, sofern es seine Gültigkeit behält, würden wir die 2^64 Bit in 45 bis 60 Jahren erreichen und das gedenke ich doch noch mitzuerleben.
Nein, 64 Bit und damit 2 ^ 64 Werte. 2 ^ 64 Bit wären ein bisschen arg viel.
...
Ja ein Denkfehler von mir. xD
8 Byte sind ja 8 mal 8 bit also 64 Bit, was einen Wert von 2 ^ 64 als Ziffer hat, hab ich jetzt verstanden
EDIT:
Aber eine Frage die sich mir anbei stellt: Wie wäre es möglich Ziffern darzustellen die größer als 2^64 sind? Muss man dafür mehrere Variablen nehmen und wie ließe sich sowas realisieren?
Es gibt dazu Implementationen von sogenannten Big Integer, gibt es glaube ich in Java nativ. Sonst kann man auch Float/double nehmen, wenn man mit der Ungenauigkeit leben kann.
Big Integer funktionieren in etwa so, dass du z.B. für jede Ziffer ein char nimmst und dann dich zurück in die Primarschule besinnst und dann alle Operationen selber implementierst. "Schriftlich" Addieren etc.
Sonst kann man auch Float/double nehmen, wenn man mit der Ungenauigkeit leben kann.
...
Da hat man aber das Problem der Implementierung und der Einstellung des Compilers. z.B. der MMX Befehlssatz rechnet mit 64 Bits Genauigkeit, während der 387 Co-Prozessor mit einer Genauigkeit von 80 Bits rechnet und 64 Bit-Genauigkeit ausgibt.
Aber eine Frage die sich mir anbei stellt: Wie wäre es möglich Ziffern darzustellen die größer als 2^64 sind? Muss man dafür mehrere Variablen nehmen und wie ließe sich sowas realisieren?
...
Irgendwann stößt du so oder so an die Grenzen des Machbaren. Was war noch gleich die größte Zahl die mit IEEE-754 machbar war? (irgendwas mit 20 Dezimalstellen oder so)
Jedenfalls wirst du nicht "unendlich" große Zahlen berechnen können.
Naja, wenn er seinen kompletten Arbeitsspeicher voll macht, kann er zumindest schonmal sehr große Zahlen speichern. Es gibt wesentlich mehr auf der Welt als nur unsigned long long int und IEEE-754.
Naja, wenn er seinen kompletten Arbeitsspeicher voll macht, kann er zumindest schonmal sehr große Zahlen speichern. Es gibt wesentlich mehr auf der Welt als nur unsigned long long int und IEEE-754.
Ein Beispiel wäre BigInteger, was Brauni90 ja schon gepostet hat. Das Konzept ist ganz leicht, auch wenn es mehrere unterschiedliche Ansätze gibt, die aber sehr ähnlich sind. Entweder du legst die Zahlen in Textform als Strings ab (dann kannst du sogar beliebig genaue Kommazahlen darstellen) oder als Byte-Array. Letzteres ist dann effektiv das gleiche, als hättest du normale long long long ... long ints. Theoretisch gehen Binary Coded Decimals auch, aber die sind beim Rechnen etwas unhandlich.
In beiden Fällen musst du natürlich alle Rechenoperationen selbst implementieren. Allerdings ist das gar nicht mal so schwer. Funktioniert wie schriftliches Rechnen in der Grundschule. Bei Addition und Subtraktion betrachtest du einfach jeweils ein Byte als eine Ziffer, verwendest die normalen Rechenoperationen und achtest auf den Übertrag. Zur Multiplikation empfehle ich das erste Kapitel von Prof. Peter Sanders' Algorithms and data structures: the basic toolbox (Google Books Link, das Kapitel kann man direkt online lesen) Wenn Bedarf besteht, kann ich dazu auch noch die Vorlesungsfolien raussuchen. Ich hatte das Glück, Algorithmen I bei Prof. Sanders zu haben. Der Mann ist wirklich kompetent.
Die Division könnte etwas schwieriger werden, ist aber auf jeden Fall auch machbar, solang man ausreichend Speicher hat.
Das hört sich verdammt intressant an o.o Werd mich mal jetzt gleich damit beschäftigen. Vom Vorlesungsstand bei mir hätte ich ehrlich gesagt selbst drauf kommen müssen (Ich sollte wohl mal wieder nacharbeiten).
Dabei nutze ich das Konzept auch um mehrere Werte in einem Int zu lagern .__.°
Erwarte aber nicht, dass deine Softwareimplementierung schnell sein wird. Besonders hinter Multiplikation und Division verbergen sich eine Unzahl an Rechenschritten, die in Software gelöst - je nach Größe der Zahl - viel Rechenleistung beanspruchen können. Theoretisch mag der Arbeitsspeicher das Limit darstellen, praktisch ist es aber die Laufzeit, denn du wirst kaum Wochen, Monate, oder mehr auf eine Berechnung warten wollen.
BCD-Arithmetik und Konsorten werden in der Regel nur im wissenschaftlichen, oder kaufmännischen Bereich benötigt. Außerhalb dieser Bereiche ist höchstens interessant zu wissen, dass es sowas gibt, oder wie es in der Theorie funktioniert, mehr nicht.