FIBONACCI in ConTeXtures (PDF),
315 KB, July 2005
Feel free to download the
PDF in German
€ 5.- only

FIBONACCI in ConTeXtures


Eine Abwendung


1. Genereller Rahmen der ConTeXtures 

1.1 Wie sind die ConTeXturen einzuordnen? 

1.2 Was ist neu zu DERRIDA'S MACHINES? 

2. Eine Metapher: Intelligentes Druckersystem 

3. Grundzüge der ConTeXtures 

3.1 Allgemeine Architektonik 

3.2 Aufbauschema der ConTeXture 

3.3 Darstellungsmethoden: Matrix, Diagramm, Klammern 

4. Proto-typische Applikationen in ConTeXtures 

4.1 Parallelitäten für Funktionales Programmieren

4.2 Algorithmischer Parallelismus = Algorithmus + Strategie 

4.3 Wer HASKELL nicht mag, kann es in SATIN haben

4.4 Basic Concepts of Parallelity in pLISP

4.5 Architektonischer Parallelismus = Algorithmus + Dissemination

5. Bilanz 


FIBONACCI in ConTeXtures


1. Frage: Einzelsysteme

Was würden wir in Bezug auf Berechenbarkeit gewinnen, wenn wir 2 oder mehr völlig autonome und vollständige Pragramme auf ebenso autonomen und vollständigen Maschinen laufen lassen würden?

Antwort: Nichts, ausser dass mehrfach dasselbe realisiert würde.

2. Frage: Kommunikation

Was würde passieren, wenn diese autonomen und separierten Programme und Maschinen miteinander kommunizieren würden indem sie ihre Daten austauschen könnten?

Antwort: Der Gewinn wäre eine deutlich erhöhte Effizienz bezüglich Rechengeschwindigkeit, Arbeitsverteilung, Medienkapazitäten, usw.

Was wir nicht gewinnen würden, wäre eine Steigerung der möglichen Berechenbarkeit. Alles was die vernetzten Kommunikationssysteme leisten können, könnte, zumindest im Prinzip, durch einen einzigen Grossrechner geleistet werden.

3. Frage: Interaktion und Reflexion

Was würden wir gewinnen, wenn diese autonomen Rechensysteme nicht nur miteinander kommunizieren, sondern auch miteinander interagieren und auf ihre Interaktionen reflektieren könnten?

Antwort: Wir würden eine Komplexion erhalten, die sich nicht mehr auf ein einziges und einzelnes System reduzieren liesse, weil ein einzelnes und einheitliches System nicht mit sich selbst interagieren kann. Interaktion, und auch Reflexion, setzen Verschiedenheit der Systeme voraus. Dies würde echte Kooperation zwischen Systemen ermöglichen, die eine höhere Komplexität aufweist als ein noch so grosses Einzelsystem. Ko-kreation von gemeinsamen Umgebungen wären möglich. Für kommunikative Systeme gilt dies nicht, da sich deren Komplexität (im Prinzip) auf einen Informationsaustausch zwischen Teilsytemen eines einzelnen Gesamtsystems ohne Umgebung reduzieren lässt.

4. Vorschlag: ConTeXtures

ConTeXtures stellt das erste Programmierungsparadigma dar, das den Anforderungen einer interaktionalen und reflektionalen Komplexion von Rechnern und Programmen gerecht wird. Interaktivität und Reflektionalität von Computersystemen sind durch ConTeXtures konzeptionell erfassbar und werden durch diese programmiert.

Wie ist das möglich?

Dies wird dadurch ermöglicht, weil die ConTeXtures auf der Grundlage der polykontexturalen Logik konzipiert sind. ConTeXtures als Programmiersystem, besteht aus einer Distribution und Vermittlung der proto-typischen Programmiersprache ARS (Loczewski), die wiederum auf dem Lambda Kalkül aufbaut. Der Lambda Kalkül ist anerkanntermassen das Grundmodell jeglicher Programmierung überhaupt und ist äquivalent dem mehr Maschinen orientierten Modell der Turing Maschine.

ARS (Abstraktion, Referenz, Synthese) wurde von Lozcewski zwar als proto-typisches System eingeführt, ist aber von ihm auch für verschiedene Programmiersprachen, wie C, C++, Scheme, Python zur Anschlussfähigkeit für Real-World-Programming weiter entwickelt worden.

ConTeXtures verstehen sich in der Tendenz dessen, was heute "Interactional revolution in computer science" (Milner, Wegner) genannt wird.

ConTeXturen sind das erste Paradigma und System der Programmierung auf dessen Basis die konzeptionellen Entwürfe von DERRIDA'S MACHINES realisiert werden können. Es bietet zudem den programmtechnischen Anschluss zu bestehenden mono-kontexturalen Programmiersprachen, vermittelt durch die Anschlüsse von ARS, und damit eine Methode zu deren Distribution und Vermittlung.

ConTeXturen erlauben es, den disseminativen Schnitt programmtechnisch zu realisieren. Der disseminative Schnitt ist die massgebliche Strategie, bestehende Programmiermethoden, -Konzepte und -Lösungen einer Heterarchisierung und damit einer Implementierung durch ConTeXtures zugänglich zu machen.

ConTeXtures zeigen jedoch ihre Stärke in einem Feld, das vorwiegend durch ambigue, polyseme und konfliktuöse Konstellationen gekennzeichnet ist und das von klassischen Paradigmen der Programmierung explizit ausgeschlossen ist. Programme müssen per definitionem disambiguiert werden. Lebensweltliche Verhältnisse, Sprache und Bedeutung, Interaktion und Reflexion, usw. sind als solche schlechtweg nicht disambiguierbar. Marvin Minskys Vorstoss zu einer Problemlösungsstrategie der "multiple ways of thinking", p-Analogy, als Prototyp einer neuen Denkweise im Entwurf von intelligenten Systemen, wird durch den Einsatz der ConTeXtures einer operativen Realisierung näher gebracht.

Konzeptionell wurde dieser Sachverhalt in aller Ausführlichkeit in DERRIDA'S MACHINES ausgeführt, ConTeXtures entwerfen zum ersten Mal ein dazu passendes generelles Paradigma der Programmierung.

http://www.thinkartlab.com/pkl/media/DERRIDA'S MACHINES.pdf

Beispiel eines autonomen reflektionalen und interaktionalen Echtzeit-Systems: ein MIRC-Druckersystem. (MIRC: mobile, interactional, reflectional, computation). Siehe auch: Autonomic computing, IBM.

Ein Drucker in einem komplexen Verbund von vernetzten Computern hat eine Fülle von Jobs zu erledigen. Heute wird dies durch eine statische Administration der Job-Hierarchie geregelt. Die Jobs sind in einer Warteschleife, die von aussen, durch einen Administrator, geregelt wird. Diese Prioritätenliste kann etwa nach dem zeitlichen eintreffen der Jobs, der grösse der Jobs oder der Priorität des Senders des Jobs, usw. geregelt werden.

Ein MIRC-Drucker ist ein lernfähiges System, das die Verhaltenspattern des Verbundes reflektiert, also seine Geschichte kennt und das durch Interaktion mit den Sendern in der Lage ist, Verhandlungen (Negotiations) durchzuführen, mit dem Ziel einer Verbund gemässen Optimierung der Prozeduren und Jobs zu gewährleisten. Und zwar während des Ablaufs der Jobs und nicht davor oder danach durch Anpassung der Prioritätenliste. Der menschliche Administrator eines solchen Systems hat nun die neue und weit reflektiertere Aufgabe, das Lernverhalten des Systems während des Veraufs zu pflegen und nicht die untere Ebene der Verteilung der Jobs, die nun vom System selbst geleistet wird.

Ein solches Druckersystem ist nun ein voll integriertes jedoch autonomes System des Gesamtverbundes und nicht bloss eine Peripherie.

Wie ist es möglich, ein solches intelligentes Druckerystem zu realisieren?

Reflektionalität und Interaktivität. Aufgrund der Separierbarkeit der Unentscheidbarkeit selbst-reflektionaler Systeme in distinkte distribuierte Systeme, wie in ConTeXtures realisiert, ist Reflektionalität und Interaktivität simultan, in Echtzeit, zum Prozessablauf möglich.

Was sind die Anforderungen an ein Interaktionssystem?

Algorithmische Systeme sind strukturell geschlossen und haben nur sekundär Zugang zu ihrer Umgebung (Turing Machine). Ihr Hauptziel ist die Optimierung der Berechnung der Algorithmen unter der Voraussetzung ihrer gesicherten Berechenbarkeit. Interaktionssysteme dagegen müssen bezüglich ihrer Reaktionsgeschwindigkeit optimiert werden. Je direkter ein System auf seine Umgebung reagieren kann, desto effizienter ist es. Reaktivität ist jedoch nicht identisch mit Rechengeschwindigkeit. Real-time computing ist primär abhängig von der Direktheit der Reaktivität und nicht von der Geschwindigkeit in der ein Algorithmus (zu Ende) berechnet wird, dessen Ausgangs-Situation (Daten, Annahmen) in der - noch so kurzen Zwischenzeit - längst obsolet geworden ist.

Als ein System der Dissemination (Distribution und Vermittlung) des Lambda Kalkül-basierten Paradigma der Programmierung ARS (Abstraction, Referenz, Synthese) mit seinem Konzept der Berechenbarkeit, sind die ConTeXtures durch die zwei grundsätzlich neuen Eigenschaften charakterisiert: Reflektionalität und Interaktionalität. Diese können als zwei Dimensionen der Dissemination von Algorithmen betrachtet werden und begründen die polykontexturale Matrix. Damit gehören die ConTeXtures zum dritten Typus der Programmierung.

Gemäss der Vermitteltheit der Teilsysteme der ConTeXtures ist die Aufbaustruktur durch Ebenen und Features charakterisiert, die in klassischen Systemen nicht existieren. Daraus ergibt sich folgende Architektonik.

Architektonik mit Templates und Patterns. Diese geben die Struktur des Systems bzgl. Reflektionalität und Interaktivität an. Configurations und Constellations regeln die verschieden Kombinationen der Topics (Datenstrukturen) und Styles (Programmierungsstile) von ARS Programmiersystemen. Eine explizite Thematisierung dieser Features kann hier nicht vorgenommen werden. Es sei auf den Text ConTeXtures verwiesen.

Dem Aufbau der Architektonik entsprechend erscheinen Fragestellungen, die die Datenstrukturen betreffen erst an später Stelle als Configurations und Constellations. Davor stehen die Strukturen der Vermittlung (Architektonik) und der Interaktionalität und Reflektionalität als Templates und Patterns. (siehe: Diagramme)

Beispiele, die die Leistungsfähigkeit von ConTeXtures beleuchten, können daher auf verschiedenen architektonischen Ebenen der ConTeXtures vorgeführt werden. Dabei sind 2 Grundtypen zu unterscheiden: Anwendung auf klassische Situationen, etwa Parallelisierung, im Gegensatz zu transklassischen Situationen (Ambiguität, Polysemy, Komplexität).

Das später diskutierte Beispiel der Berechnung der Fibonacci Zahlen, bezieht sich auf den Topos Numbers und den Style Functional Programming. Entsprechendes kann für die Objekt-orientierte Programmierung vorgeführt werden, wie dies insb. für ein Dynamic Semantic Web von Wichtigkeit ist (Heterarchisierung von Ontologien und Datenbanken).

Das allgemeine Aufbauschema der ConTeXtures hat als "header" die globale heterarchische Organisationsstruktur der Verteilung und Vermittlung der lokalen ARS-Systeme, die im "body" des Aufbaus erscheinen. D.h., eine gewählte Heterarchie als Horizont und Architektonik strukturiert die disseminierten Hierarchien. Diese wiederum enthalten die Angaben über Weisen der Programmierung (Styles) und Datentypen (Topics), während der header die Strukturen der Interaktivität und Reflektionalität einer entworfenen Komplexität organisiert, die wiederum durch ihre categories, patterns und templates enthaltend, konkretisiert wird.

Lokalisiert werden die ARS Systeme durch identify contexture, ihr Apparat wird mit define, abstract bzw. lambda und den statements bestimmt.

Operatoren-Schema:

samba (architectonics

(reflectionality (interactivity

(define (lambda (statements )))))

Distribution und Vermittlung von vollständigen ARS Programmier-Systemen in der polykontexturalen Matrix. Nicht belegte Stellen der Matrix werden mit einem Leerzeichen, etwa #, versehen, oder aber, aus stilistischen Gründen, nicht notiert.

Diagramme visualisieren die Verteilung der Algorithmen und deren Interativität und Reflektionalität. Diagramme haben wenig operative Aussagekraft und werden schnell unübersichtlich.

Die Klammerdarstellung lässt sich als Formalismus verstehen, der die oben genannten Eigenschaften abbildet und deren iterative Muster übersichtlich darzustellen in der Lage ist.

Die Matrix bietet eine andere Visualisierung an, die auch als Formalismus dienen kann.

Alle drei Formen reflektieren die grundsätzliche Zweidimensionalität, gebildet, hier, durch Interaktivität und Reflektionalität der disseminierten Algorithmensystemen. Damit wird schon auf architektonischer Ebene der der semiotische Zeilenzwang (Max Bense), seine Linearität und Atomizität der Zeichen logozentrischer Formalismen definitiv zu Gunsten einer graphematischen Tabularität der Inskriptionen verlassen.