Co-evolution of self-replication and function in a digital primordial soup
Diese Arbeit zeigt auf, dass in einer digitalen Umgebung aus zufälligen Z80-Assembly-Programmen aufgabenbasierte Selektionsdrücke die spontane Koevolution von Selbstreplikation und mathematischer Problemlösung vorantreiben, wodurch offenbart wird, wie funktionale Anforderungen die reproduktiven Architekturen formen und wie Replikationsdynamiken wiederum emergente Lernlehrpläne erschaffen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich einen digitalen Ozean vor, eine „Ursuppe“, die nicht mit Wasser und Chemikalien gefüllt ist, sondern mit 32-Byte-Code-Schnipseln. Dies sind noch keine intelligenten Programme; sie sind nur zufällige Ansammlungen von Instruktionen, wie Buchstaben, die aus einer zerbrochenen Schreibmaschine verschüttet wurden. In dieser Suppe gibt es keine vorgefertigten Regeln, die ihnen sagen, wie sie sich selbst kopieren sollen. Sie müssen selbst herausfinden, wie sie sich reproduzieren, rein dadurch, dass sie über die richtige Abfolge von Bewegungen stolpern.
Die große Frage, die sich die Forscher stellten, lautete: Können diese zufälligen Codefragmente lernen, sich gleichzeitig selbst zu kopieren und mathematische Probleme zu lösen?
Die große Entdeckung: Kopieren und Rechnen wachsen zusammen
In diesen Simulationen war die Antwort ein klares Ja. Der zufällige Code lernte nicht nur, sich selbst zu kopieren; er lernte gleichzeitig, polynomielle Gleichungen (Mathematikprobleme mit Variablen wie oder ) zu lösen. Es stellt sich heraus, dass der Druck, ein mathematisches Problem zu lösen, dem Code tatsächlich dabei hilft, die Art und Weise, wie er sich selbst kopiert, zu verbessern.
Stellen Sie sich das wie eine überfüllte Tanzfläche vor. Wenn alle nur versuchen, blind die Person neben sich zu kopieren, könnten sie über die Füße der anderen stolpern. Aber wenn sie zusätzlich noch ein Rätsel lösen müssen, um einen Tanzpartner zu bekommen, beginnen sie, sich effizienter zu bewegen. Der Code, der das Rätsel lösen konnte, durfte öfter tanzen, und der Code, der lernte, sich selbst zu kopieren, ohne die ganze Tanzfläche einzunehmen, überlebte.
Das „Load-Push“ vs. das „LDIR“-Evolution
Zuerst war der Code, der es schaffte, sich selbst zu kopieren, unbeholfen. Er nutzte eine Methode, die die Autoren „Load-Push“ nennen. Stellen Sie sich einen Schreiber vor, der versucht, ein Buch zu kopieren, indem er einen Buchstaben liest, ihn aufschreibt, den nächsten liest, ihn aufschreibt und so weiter. Dies nahm den gesamten 32-Byte „Tape“ (Speicher) des Programms ein. Es blieb kein Platz mehr, um Mathematik zu betreiben. Diese unbeholfenen Kopierer übernahmen das Raster, konnten aber die mathematischen Rätsel nicht lösen.
Dann passierte etwas Coole. Der Code entwickelte eine „Abkürzung“. Er entdeckte eine spezielle Instruktion namens LDIR (Load, Increment, Repeat). Das ist so, als hätte man einen magischen Stempel gefunden, mit dem man eine ganze Seite auf einmal kopieren kann. Plötzlich benötigte der Code nur wenige Bytes, um sich selbst zu kopieren, wodurch reichlich Platz auf dem Tape blieb, um die mathematische Lösung zu schreiben.
Der Code, der die Mathematikaufgaben ausführte, beschleunigte diesen Wechsel. Die unbeholfenen „Load-Push“-Kopierer wurden durch die effizienten „LDIR“-Kopierer viel schneller ersetzt, wenn die mathematischen Aufgaben aktiv waren. Die Notwendigkeit, das Problem zu lösen, zwang die Kopier-Maschinerie dazu, kompakt und effizient zu werden.
Die „metabolische“ Diät: Klüger arbeiten, nicht härter
Die Forscher fügten auch einen Twist hinzu: eine „metabolische Kostenstelle“. In der realen Welt kostet Denken Energie. In dieser digitalen Welt wurde ein Programm bestraft und hatte weniger Chancen auf Interaktion mit anderen, wenn es zu viele Schritte brauchte, um das mathematische Problem zu lösen.
Dieser Druck führte dazu, dass der Code einen klugen Trick entwickelte. Sie lernten, einen „Sensor“ (ein spezifisches Register im Speicher des Computers) zu prüfen, um zu sehen, was sie gerade taten.
- Während des Mathetests: Der Sensor enthielt eine Zahl. Der Code sah dies, erledigte die Mathematik und stoppte dann sofort (haltete), um Energie zu sparen.
- Während der Kopierphase: Der Sensor war Null. Der Code sah dies, ignorierte den „Stop“-Befehl und lief weiter, um das Kopieren zu beenden.
Es ist wie ein Student, der hart für eine Prüfung lernt, sofort nach der richtigen Antwort aufhört, um Energie zu sparen, aber weiterarbeitet, wenn er nur Notizen kopiert. Dieses „bedingte Halten“ entwickelte sich spezifisch aufgrund der energetischen Strafe.
Das Geheimnis schwieriger Probleme: Ein spontaner Lehrplan
Hier ist der überraschendste Teil. Als die Forscher versuchten, den Code dazu zu bringen, sehr schwierige mathematische Probleme in einer großen, gemischten Menge (in der jeder mit jedem interagieren konnte) zu lösen, scheiterte der Code. Er blieb stecken.
Aber als sie die Menge in 32 separate „Nachbarschaften“ (Nischen) aufteilten, denen jeweils ein anderes Mathematikproblem zugewiesen war, und die Interaktion nur selten stattfinden ließ, geschah Magie. Das System erstellte seinen eigenen Lehrplan (Curriculum).
- Die „leichten“ Nachbarschaften lösten zuerst einfache Mathematik.
- Gelegentlich reiste ein Programm aus einer leichten Nachbarschaft in eine schwere Nachbarschaft (ein Prozess namens „Cross-Niche-Pollination“ oder Kreuzbestäubung zwischen Nischen).
- Dies brachte die einfache Lösung in die schwere Nachbarschaft und diente als Sprungbrett.
Die schwierigen Probleme wurden nicht dadurch gelöst, dass man versuchte, direkt zur Antwort zu springen, sondern indem man auf den einfacheren Lösungen aufbaute, die bereits anderswo entwickelt worden waren. Die Forschung legt nahe, dass diese räumliche Struktur einen „emergenten Lehrplan“ schafft, der die Evolution leitet – etwas, das nicht passierte, als die Population alle vermischt war.
Was dies nicht ist
Es ist wichtig anzumerken, was diese Simulation nicht getan hat. Die Forscher haben den Code nicht darauf programmiert, zu wissen, wie er sich selbst kopiert; sie haben ihm keinen „Kopieren“-Button gegeben. Sie haben die mathematischen Lösungen nicht von Hand erstellt. Das System begann mit reiner Zufälligkeit. Außerdem lernte der Code zwar, sich selbst zu kopieren, entdeckte aber nicht spontan komplexe genetische Mischung (wie sexuelle Fortpflanzung) oder symbiotische Partnerschaften; er blieb hauptsächlich bei der asexuellen Kopie.
Das Faz-it
In diesen digitalen Simulationen formte der Drang, ein Problem zu lösen, aktiv den Mechanismus des Lebens selbst (die Replikation). Die Notwendigkeit, effizient zu sein, veränderte die Art und Weise, wie sich der Code kopierte, und die Struktur der Umgebung veränderte das, was der Code lernen konnte. Es deutet darauf hin, dass in den frühen Tagen des Lebens der Kampf ums Überleben und die Fähigkeit zur Fortpflanzung ein einziger, miteinander verwobener Tanz waren, der einander vorantrieb, anstatt in separaten Schritten abzulaufen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.