(Dieser Beitrag wurde zuerst publiziert in: Zehn Paradebeispiele gegen Zufalls-Evolution, 1991 zusammengestellt von W.-E. Lönnig, Naturwissenschaftlicher Verlag Köln. ISBN 3-9801772-2-X)

Die Wahrscheinlichkeitsrechnung geht von der falschen Voraussetzung aus, dass die bestimmte genetische Information auf einmal entstanden sein müsse. Die Evolutionstheorie geht jedoch davon aus, dass diese in vielen kleinen Schritten systematisch durch Mutation und Selektion aufgebaut wurde. Es reicht doch aus, zu Zwischenstufen zu gelangen, die bereits einen Vorteil gegenüber anderen Lebewesen bieten und mit diesen dann weiter zu experimentieren.

Ein bekannter Prozess der Informationsentstehung ist die Softwareentwicklung. Wir können davon ausgehen, dass Programme, die mehr Fähigkeiten haben als andere, sich besser vermarkten lassen und so einen Überlebensvorteil haben, eine Situation, die der der Lebewesen sehr ähnlich ist. Die Untersuchung der Informationsentstehungsmechanismen bei Programmen liefert eine empirische Grundlage für weitere Folgerungen.

In der Programmierung hat man ständig das Phänomen, dass durch Intelligenz Information entsteht, die Computer wissen hinterher, was sie sollen und was nicht. Es soll einmal an Hand eines Beispiels untersucht werden, ob auch ein intelligenzfreier Mechanismus (wie das Zusammenspiel von Mutation und Selektion) in der Lage ist, Information zu erzeugen und so vermarktbare Software entstehen zu lassen. Das betrachtete Beispiel ist repräsentativ.

Betrachten wir nur einmal ein recht einfaches Problem. Gehen wir der Frage nach: Könnte eine Sortierroutine auch durch einen Mutations- Selektionsmechanismus, beispielsweise in der Programmiersprache C entstehen? (Die Lage ist in anderen Programmierspachen ähnlich!) Schätzen wir dazu zunächst einmal das Verhältnis

Mögliche Mutationen / Mutationen mit verbesserter Sortierwirkung

ab. Für einen Sortiervorgang unbedingt notwendig ist der Vergleich von zwei Speicherzeilen oder Feldelementen, es muss festgestellt werden, welches Feldelement das größere ist und in Abhängigkeit von diesem Vergleich dann eine Vertauschung der Feldelemente vorgenommen werden. Betrachten wir zunächst die Kodierung eines Größer-Kleiner-Vergleiches. Im Vergleich erwähnt werden müssen die beiden Speicherzellen, die verglichen werden sollen und der Vergleichsoperator. Die beiden kürzesten Formulierungen für einen solchen Vergleich, ob a größer als b ist, lautet

a>b oder

b<a.

Man kommt beim Vergleichen für Sortierungen nicht ganz so einfach, die zu sortierenden Werte werden auf einem "Feld" abgespeichert, die einzelnen Feldelemente durch Indizes angesprochen. Ein Index bezeichnet das Feld, in welches der kleinere Wert der beiden gehört, der andere das Feld für den größeren Wert. Es muss festgestellt werden, ob der Wert in dem Feldelement mit kleinerem Index auch wirklich den kleineren Wert enthält, andernfalls müssen die beiden Feldelemente vertauscht werden. Der Name eines Index kostet mindestens ein Zeichen, welches durch das eckige Klammerpaar [] eingerahmt wird. Der reine Vergleich benötigt wegen der Indizierung mindestens 9 Zeichen:

z [i] < z [j]

Dazu kommen noch die Zeichen

if ()

die bewirken, dass die durch {} geklammerten Befehle nur dann ausgeführt werden, wenn die Bedingung erfüllt ist. Das ergibt zusammen 9+4=13 Zeichen:

if (z [i] < z [j])

Die (kürzeste) alternative Formulierung wäre:

if (z [i] > z [j])

Diese beiden Formulierungen bieten einen Faktor 2 an Möglichkeiten. Eine weitere Freiheit besteht bei der Namensgebung. Die Namen i, j und z sind nicht zwingend, sie müssen lediglich paarweise verschieden sein. Ihre Richtigkeit ist kontextabhängig. An einstelligen Variablennamen kommen 26 Groß-, 26 Kleinbuchstaben und das Zeichen "_", also zusammen 53 Zeichen an. Wenn diese paarweise verschieden sein sollen, so ergeben sich dafür

53 * 52 * 51 = 140 556

Möglichkeiten. Insgesamt ergeben sich damit wegen der alternativen Formulierung des Vergleiches

140 556 * 2 = 281 112

richtige Möglichkeiten für eine Ausformulierung des Vergleiches. Der Vergleich allein reicht aber nicht aus, wenn er der Sortierung etwas nützen soll, die beiden Felder müssen auch noch vertauscht werden. Die Vertauschung ist nur nach dem "Rangierprinzip" möglich. Der Inhalt eines Feldelements wird auf eine Puffervariable gespeichert, bevor er durch den Inhalt des anderen Feldelementes überschrieben wird. Danach wird der Inhalt des anderen Feldelementes durch die Puffervariable überschrieben. Beispiel: Die Inhalte von x und y sollen vertauscht werden. Die Zuweisung

x = y;

führt dazu, dass der alte Wert von x überschrieben wird und diese Information dann verloren ist. Diese Information wird aber noch benötigt, um y den früheren Wert von x zuzuweisen. Daher muss man folgendes machen:

p = x; x = y; y = p;

Die Anweisung p = x; rettet den Inhalt von x auf p. Danach kann durch x = y der Wert von x durch y überschrieben werden. Die noch benötigte Information für die Zuweisung an y steht noch in p und wird dann durch y = p; zugewiesen. Es gibt aber noch eine symmetrische Lösung für das Rangierproblem, man muss ja nicht unbedingt x auf p retten, man kann das auch mit y tun. Die symmetrische Lösung lautet also:

p = y; y = x; x = p;

Die Symmetrie der Lösungen liefert einen Faktor 2 für die Anzahl der richtigen Möglichkeiten. Die ";" bedeuten, dass der Befehl zu Ende ist. Da jedoch bei einer Sortierung indizierte Variablen ausgetauscht werden müssen, benötigt man mindestens einen Austauschvorgang folgender Länge:

p = z [i]; z [i] = z [j]; z [j] = p;

Dieses Befehlstriplett muss aber hinter dem Vergleich in den geschweiften Klammern {} stehen, um zu kennzeichnen, dass diese als ganzer Block ausgeführt werden sollen oder auch nicht, je nachdem, was der Vergleich ergab. Die vollständige Vertauschung nach dem Vergleich lautet:

{p = z [i]; z [i] = z [j]; z [j] = p;}

Die ersten beiden ";" können durch "," ersetzt werden, das gibt einen Faktor 4 an richtigen Möglichkeiten. Einen weiteren Faktor für richtige Möglichkeiten erhält man durch Umbenennung der Variablen p, z, i und j, deren Namen, wie vorhin auch, nur paarweise verschieden sein müssen. Das ergibt

53 * 52 * 51 * 50 = 7 027 800

Möglichkeiten. Durch mögliche Ersetzung von ";" durch "," und Symmetrie der Vertauschung kommt nach ein Faktor van 4 * 2 = 8 hinzu. Man erhält insgesamt für den Vertauschungsvorgang

8 * 7 027 800 = 56 222 400

Möglichkeiten bei einer 26-stelligen Zeichenfolge. Zusammen mit dem Vergleich lässt sich die Zahl der insgesamt richtigen Möglichkeiten durch

281 112 * 56 222 400 = 15 804 791 308 800

nach oben abschätzen, dass die Namen der im Vergleich und der Vertauschung verwendeten Variablen nicht unabhängig voneinander sind und daher in Wirklichkeit weniger Möglichkeiten bestehen, braucht hier nicht weiter berücksichtigt zu werden. Der bei einer Sortierung benötigte Vergleich mit möglichem Austausch benötigt mindestens 39 Zeichen, unter den möglichen 39-stelligen Zeichenketten sind etwa 16El2 brauchbare Zeichenketten. Um das Verhältnis brauchbare/mögliche Zeichenketten nach oben abzuschätzen, muss jetzt noch der Nenner nach unten abgeschätzt werden. (Der Zähler ist bereits nach oben abgeschätzt.) Zulässige C-Zeilen sind Variablennamen, gefolgt von ";" z.B.:

HalloDuSchoeneWelt;

Variablennamen müssen mit einem Buchstaben oder "_" beginnen und können danach nach Belieben Buchstaben, Ziffern oder "_" enthalten. Wegen dem obligatorischem ";" am Schluss ergeben sich damit mindestens

53 * 63³⁷ = 6,23E114

richtige 39-stellige C-Zeilen. Das Verhältnis brauchbare/mögliche Zeichenketten lässt sich damit durch

16E12/6,23E114 = 1/2.57E102

nach oben (!) abschätzen, in Wirklichkeit ist es kleiner!

Man ist in der Programmierpraxis ja nicht gezwungen, auf dem kürzest möglichem Weg zu programmieren. Die Frage ist nun, wie sich das Verhältnis ändert, wenn man zu längeren Zeilen übergeht. Dazu bieten sich folgende Möglichkeiten.

- Kommentare
- Längere Vergleichsoperationen
- Längere Variablennamen

Kommentare bewirken nichts im Programm. Die Anzahl der möglichen Kommentare bei brauchbaren und unbrauchbaren Möglichkeiten ist die selbe, sie kürzt sich heraus.

Längere Vergleichsoperatoren verringern das Verhältnis brauchbar/möglich, da zu jedem Vergleichsoperator ein Vielfaches von Nichtvergleichsoperatoren gefunden werden kann. Z.B: Auf

if (a<b) ...

kommen

if (###) ...

wobei hier ### für alle zulässigen dreistelligen Variablennamen steht, was syntaktisch richtig ist, aber keine sinnvolle Anweisung ist, geschweige eine, die syntaktisch richtig ist. Bläht man den Vergleich auf zu z.B.

if (a-b<0) ...

so kann man die Nicht-Buchstaben durch eine Vielzahl von Buchstaben ersetzen, was das Verhältnis brauchbare/mögliche Zeichenketten verringert.

Längere Variablennamen verringern das Verhältnis brauchbare/mögliche Zeichenketten ebenfalls, die Variablennamen müssen in der Zeichenkette mehrmals an den richtigen Stellen erwähnt werden. Z.B:

p = x; x = y; y = p;

Beim zweiten x hat man nur 52 Möglichkeiten, einen einstelligen Variablennamen falsch einzusetzen, bei einem zweistelligem Variablennamen, z.B. "xx"

p = xx; xx = y; y = p;

hat man 53 * 63 - 1 = 3338 Möglichkeiten, ihn an der zweiten Stelle durch einen falschen Namen zu ersetzen.

Die Programmierung des Teilproblems der sinnvollen Austauschung von Feldelementen ist für einen Mutations- Selektionsmechanismus ohne planende Intelligenz undenkbar. Auf eine richtige Möglichkeit mit mindestens 39 Zeichen, Vorstufen haben ja noch keinen Selektionswert, kommen mindestens 2.57E102 Möglichkeiten, das ist ein 103-stellige Zahl, die für eine Sortierung sinnlos sind.

Man kann abschätzen, ob eine derartige Information sich im Laufe der Geschichte des Universums sich hätte auf der Erde durch Mutation und Selektion in einem Individuum bilden können: Nimmt man für das Alter des Universums 1E20 Generationen an und ferner, dass pro Generation 3,6E51 Versuche gleichzeitig möglich sind, (nähere Begründung für diese Abschätzung siehe Lönnig: Kann der Neodarwinismus durch biologische Tatsachen widerlegt werden?, p. 29), so müssten 7.1E30 Versuche pro Generation pro Individuum gemacht werden, um einmal durch Mutation und Selektion eine Codierung für "sinnvolle Vertauschung" zu erhalten.

In der Computerprogrammierung sind Mutation und Selektion im Gegensatz zu Intelligenz aus Wahrscheinlichkeitsgründen völlig unbrauchbare Mechanismen zur Informationserzeugung. Selbst im Laufe von mehreren Milliarden von Jahren kommen Mutation und Selektion zusammen nicht als informationsaufbauende Mechanismen in Frage. Gründe, warum Mutation und Selektion zusammen in biologischen Systemen anders als bei der Programmierung als informationsaufbauende Mechanismen fungieren könnten, sind mir bislang nicht bekannt, zumal das Problem das selbe ist: Kann eine Funktion ausgeübt werden oder nicht.