Computer müssen auch negative ganze Zahlen darstellen können, also zu 24 sollte es auch eine -24 geben.
Erste Idee (keine gute): Einerkomplement
Man könnte die Bitfolge der natürlichen Zahl negieren. Zur Zahl 6[10] = 0110[2] wäre dann -6[10] = 1001[2].
Damit gibt es allerdings ein Problem: zur Zahl 0[10] = 0000[2] gäbe es eine "negative Null: -0[10] = 1111[2]! Die Null ist jedoch einmalig, zur ihr darf es kein "Gegenstück" geben.
Lösung: Zweierkomplement
Die Lösung ist so einfach: Im Dezimalsystem entsteht bei der Addition der positiven und negativen Zahl stets Null. Wir suchen also eine Binärzahl n zu beispielsweise 5[10] = 0101[2], für die gilt 0101[2] + n = 0000[2]. Durch Probieren finden wir -5[10] = 1011[2]. Die Addition ergibt zwar einen Übertrag auf die Stelle 24, aber das blenden wir aus.
Können wir aus dem Probieren eine Regel entwickeln? Klar:
- Bilde das Einerkomplement der Binärzahl = Negiere die Bitfolge der Binärzahl
- Erhöhe das Ergebnis aus 1.) um eins = Inkrementiere das Ergebnis.
Gibt es noch unsere "negative" Null?
Nein, da:
- Einerkomplement: 0000[2] → 1111[2]
- Inkrement: 1111[2] → 0000[2]
Im Zweierkomplement sind alle Binärzahlen, bei denen das höchste Bit den Wert 1 hat, negativ. Mit vier Bit lassen sich die Zahlen von -8[10] = 1111[2] bis 7[10] = 0111[2] bilden.
Probleme bei der Zahldarstellung: 7 + 1 = -8?
Inkrementiert man 7[10] = 0111[2], so erhält man 1000[2] = -8[10]!
Der Zahlbereich der ganzen Zahlen ist als endlicher Zahlenkreis darstellbar. In diesem gibt es eine Problemstelle, nämlich den Übergang von der höchsten darstellbaren Zahl zum Nachfolger. Programmierer müssen daher stets auf den Wertebereich des Datentyps achten, um keine fehlerhaften Berechnungen durch den sogenannten Überlauf zu erzeugen.
Und was ist mit reellen Zahlen?
Die Abbildung reeller Zahlen auf dem Computer ist defacto unmöglich. Man nutzt Hilfskonstrukte wie die Gleitkommadarstellung. Diese ist jedoch endlich und diskret, d. h. zwischen zwei Zahlen ist eine Lücke. Die Differenz zu nächst möglichen Gleitkommazahl ist ein Fehler, der sich bei umfangreichen Rechnungen auch sehr schnell summieren und zu ernsthaften Konsequenzen führen kann.
Das kann man auch schnell selbst ausprobieren: Was passiert in Java/Python, wenn man 0.1 und 0.2 addiert?