LawsOfForm

Heute ist der Abschied eines wunderbaren Menschen: Peter Krieg. Peter ist am 22.07.2009 an den Folgen einer schweren Operation gestorben. Peter hat unter anderem das Buch “Die Paranoidie Maschine” geschrieben, außerdem beschäftigte er mich sehr mit Pile Systems in den letzten Jahren.

Kürzlich bin ich auf einen sehr interessanten Graduiertenkolleg in Paderborn gestoßen. Der Graduiertenkolleg beschäftigt sich mit sog. Automatismen. Automatismen sind nicht planbare – aber effiziente und effektive – Prozesse (sofern man von Prozessen sprechen darf). Für Automatismen sind u.a. auch strukturbildende Informationsflüsse zwischen Individuen relevant.

Als ich das neue Paper “Freeing Data From the Silos” von Ralf gelesen habe, wurde mir einiges “klarer”. Besonders interessant fand ich das Beispiel mit der Pile-Relationsstruktur für ein ASCII-A und die Veranschaulichung, wie durch das Traversieren von einer Relation zu den Tops das ASCII-A aus dieser Relationsstruktur erzeugt werden kann. Ganz im Sinne “erkenne um zu handeln, handle um zu erkennen” dachte ich mir, “Okay, jetzt hast du erkannt/gesehen – jetzt muss ich handeln, um noch mehr über Pile zu lernen”. Um meine Lern-Feedbackschleife zwischen “Theorie” und “Praxis” ins “Rollen” zu bringen dachte ich mir, das Paper von Ralf ist ja so konkret, das ich hierzu doch einmal eine handvoll Javaklassen programmieren könnte mit einer rekursiven traverseUp()-Methode, um Daten aus einer Pilestruktur zu erzeugen. Gesagt – getan – abends, parallel zu einem der WM-Fußballspiele (Fußball hat nicht ganz eine so hohe Bedeutung für mich – deshalb kann ich mich nicht mehr genau daran errinnern, wer gegen wen spielte).

Top white = new Top("white");
Top black = new Top("black");
Relation wb = new Relation(white,black);
Relation ww = new Relation(white,white);
Relation wwwb = new Relation(ww,wb);
Relation wbww = new Relation(wb,ww);
Relation wbww_wwwb = new Relation(wbww,wwwb);
Relation wbww_wwwb_wb = new Relation(wbww_wwwb,wb);
PileEngine pe = new PileEngine();
pe.printTops(wbww_wwwb);

Die zweite Java-Klasse ist die Klasse PileEngine.java was etwas übertrieben ist. Derzeit enthält diese Klasse lediglich meine Methode traverseUp(), die sich rekursiv selbst aufruft.

An dieser Stelle möchte ich auf darauf hinweisen, das eine Pile-Relation intern nicht weiß, was Sie darstellt. Wenn ich das Konzept richtig verstanden habe wird durch die “äußeren Pile-Architektur-Layer” das Konzept des Beobachters realisiert. D.h. erst der Beobachter bestimmt die Bedeutung der Pile-Relation. Hierzu gibt es dann nach dem PileSpace die PileSpaceEngine, die PileEngine und den PileAgent (vgl. hierzu auch meine ersten Auseinandersetzungen mit Pile – Auf dem Weg zu Pile). Ich weise deshalb an dieser Stelle darauf hin, das es sich hier nur um eine Quick-And-Dirty-Learning-Implementation meiner Klassen handelt mit keinem Anspruch auf Vollständigkeit. D.h. ich lege hier im Moment noch keinen Wert auf die explizite Trennung und die Terminologie Relation, Top, TerminalValue – ich vermische die Begriffe codetechnisch. Ich verzichte auch bewußt auf die Darstellung der Relationen als 2D-Koordinaten, wie es der Code pilespace.cpp von Ralf umsetzt (vgl. auch JNI-Wrapper für Pile). Zum Erlernen und Verstehen, ist mir meine derzeitige Abbildung zugänglicher.

public void printTops(Relation r)
{
    traverseUp(r);
}
private void traverseUp(Relation r)
{
    Relation normative = r.getNormative();
    if(!normative.isTop())
    {
        traverseUp(normative);
    }
    else
    {
        System.out.println(((Top)normative).getSymbol());
    }
    Relation associatve = r.getAssociative();
    if(!associatve.isTop())
    {
        traverseUp(associatve);
   }
    else
    {
        System.out.println(((Top)associatve).getSymbol());
    }
}

Folgende Grafik gibt die Aufrufreihenfolge durch eine GIF-Animation wieder. Wenn Du auf die Grafik klickst, erhälst Du diese Animation als PDF-Dokument.

Nachstellung der traverseUp()-Methode für ein ASCII-A

Durch das Handeln (Programmieren) nach dem Sehen (Erkennen) drängen sich mir nun folgende Fragen auf, die ich versuchen werde künftig zu beantworten:

1. Wie kann eine PileEngine.assimilate()-Methode aussehen, welche eine Bitsequenz assimiliert, um eine PileRelation zu erzeugen?
2. Wie könnte eine PileEngine.query()-Methode aussehen, welche als Input eine Bitsequenz erhält und als Antwort eine Kontext-Information der Bitsequenz zurückgibt bzw. mit “Ja” oder “Nein” antwortet, ob die Pilerelation diese Bitsequenz überhaupt enthält erzeugen könnte.
3. Reicht für die beiden Operationen 1+2 die aktuelle Implememtierung meiner Klasse Relation.java aus? Ich vermute nicht, denn die Klasse enthält lediglich zwei Pointer: den NormativePointer (Np) und den AssociatePointer (Ap). Ich vermute einmal meine Struktur benötigt noch Top-Down / Parent-To-Child-Pointer.
4. Darüber hinaus stellt sich mir die Frage, inwiefern das “Setzen einer Relation” in einer Pile-Relationsstruktur verglichen werden kann mit dem “Treffen einer Unterscheidung im Raum” nach Spencer-Brown. Denn: das Vollziehen des Prozesses der Unterscheidung schafft eine Form. Das Setzen einer Relation innerhalb einer Pile-Relation schafft ebenfalls etwas Neues. Eine Pile-Relation hat ebenfalls “zwei Seiten”: den NormativePointer und den AssociatePointer. Evtl. sind diese mit dem “marked” und “unmarked” Space nach Spencer-Brown vergleichbar?

So, dann fehlen ja nur noch die Java-Klassen zum download. Du findest sie hier: JPile-TraverseDemo. Pile ruleZ!

Super, das neue Pile Paper “Freeing Data From the Silos – Pile explained” von Ralf Westphal ist da. Was ich auf dem ersten Blick sehe, ist, das Ralf dem Erzeugen von Daten aus einem Pilespace besondere Aufmerksamkeit schenkt. Vielleicht komme ich dem Ganzen jetzt näher. Insbesondere was das Traversieren von normativen und assoziativen Teilbämen angeht. Sobald ich dazu komme werde ich mir die leckere Lektüre zu Gemüte führen ….

Auf dem Weg zu mehr Erkenntnis zu den Laws ist mir natürlich schon der Gedanke durch den Kopf gegangen, was Pile wohl mit den Laws zu tun hat? Mittlerweile ist mir auch klar, das man mit den Laws weit mehr machen kann als rangierende Züge in einem Tunnel zu zählen. Bisher bin ich jedoch leider nicht auf die konkrete Dokumentation des Spencer-Zählers getroffen (hilft bestimmt für das Verständnis); die Erfindung soll ja nach Felix Lau patentiert und nach wie vor in der Anwendung sein. Da mir nach wie vor der mathematische Zugang schwer fällt habe ich mich entschlossen parallel auch den philosophischen Zugang zu den Laws zu versuchen. Dazu habe ich mir die “Löwenzähne” von Spencer Brown geholt, sowie das Buch “Die Form der Paradoxie” von Felix Lau. Auf das Buch von Felix Lau bin ich gestossen, weil ich durch die deutsche Übersetzung der “Definition”¹

“Unterscheidung ist perfekte Be-Inhaltung” (LoF von Thomas Wolf)

an Ying-Yang denken musste und Felix Lau sich in Kapitel III “Eine formtheoretische Erkenntnistheorie” mit dem Begriff des re-entrys und Ying-Yang auseinandersetzt. Bezüglich der “Definition” führt Felix Lau auf Seite 40 in seinem Buch aus, das durch die Unterscheidung eines Kreises in einer Ebene durch die vollständige Schließung perfekt ist: “Sie schließt dieses ein und jenes aus”. Durch den Kreis wird “perfekt be-inhaltet”. Tatjana Schönwälder und Katrin Wille setzt sich mit der “Definition” etwas anders auseinander, von dem englishen Originaltext ausgehend (ab Seite 67):

“Distinction is perfect continence”

Dabei spielt die Bedeutungsvielfalt des Begriffes continence im Englischen eine besondere Rolle. Hier führen Sie den Leser zum Begriff des Zusammenhangs:

“… Das Verb (continere) hält aber auch die geometrische Verwendung bereit im Sinne von ‘zusammenhalten’ …”

Letztendlich kommen Sie zu dem was ich in dem Ying-Yang-Symbol sehe: (1) Die perfekte Einschließung eines Bereiches, der innere Zusammenhalt eines Bereiches (schwarz, weiß, gut, böse, …), (2) Der Zusammenhang, das eines etwas anderes ausschließt und (3) die Verbindung von (1) und (2), das durch den Zusammenhang/die Relation aus (1) und (2) erst etwas erscheint (das überhaupt erst etwas unterscheidbar wird). Oder so: durch das Ziehen einer Grenze entsteht das Eingeschlossene und das Ausgeschlossene. Was dadurch entsteht (z.B. ein Kreis) wird sichtbar durch die Relation zwischen Engeschlossenem und Ausgeschlossenem, pefekte Be-Inhaltung im Sinne von “perfect continence”, also Zu-sammenhang.
Interessant finde ich bzgl. LoF und Pile die Ausführungen von Ralf Barkow in seinem Blog zum Thema Pile Combinative Pointer. Ich bin mir sicher das es sich lohnen wird weiter in Pile einzusteigen. Mein nächster Schritt, um Pile besser zu verstehen wird die Implementierung des Layers darstellen, der auf den Pile-DLL-Kern aufsetzt, die Pile-Engine. Die parallelen zwischen Pile und den Laws ist mir jetzt auch mehr klar geworden:

1. Die Laws beschreiben die Entstehung von Etwas durch den Akt der Unterscheidung und geht nicht von Objekten oder etwas wie Entitäten aus
2. In Pile existieren ebenfalls keine Entitäten, sondern ausschließlich Relationen von Atomen und Relationen von Relationen. Durch das Traversieren der normativen und assoziativen Bäüme im PileSpace lässt man etwas entstehen

Von daher glaube ich, das sich die intensive Auseinandersetzung mit Pile und den Laws gegenseitig befruchten wird. Ich habe hier das Gefühl, das die Auseinandersetzung mit dem einen (z.B. Pile) Zugänge zu dem anderen (z.B. Laws) ermöglicht und umgekehrt. So wurde mir z.B. die Zirkularatmung für das Didgeridoospielen zugänglich, indem ich eine Yoga-Pranayama-Atemübungen beim Didgeridoospielen durchgeführt hatte. Plötzlich hatte ich in beiden Bereichen Zugänge, die mir zuvor verschlossen blieben.

Gut! Jetzt habe ich eine erste Variante meines JPile-JNI-Wrappers für den Code pilespace.cpp von Ralf. Ich stelle den Code hier gerne zur Verfügung, möchte aber hinweisen, das ich den Code in der Freizeit nebenher auf die “Schnelle” mit der “heissen Nadel” gestrickt habe. U.a. habe ich alle nur erdenklichen Java-Patterns “missachtet”, so habe ich z.B. die Methodennamen in der Datei PileSpaceJNI.java groß geschrieben, um möglichst nahe an der C/C++-Version von Ralf zu bleiben. Außerdem habe ich kein Factory-Pattern oder einen Singleton implementiert, obwohl ich denke das dieses Pattern sehr sinnvoll wäre. Ebenso habe ich keinerlei Java-Paketierung verwendet. Ich empfehle aber, eine Paketstruktur der Art pile.space.* zu verwenden. Mir ging es in diesem Schritt ausschließlich darum (1) etwas über JNI zu lernen und (2) den PileSpace-Kern in Form einer Win32-DLL für die Java-Welt zugänglich zu machen.

Wie bin ich vorgegangen?

Implementieren der PileSpaceJNI.java

In dieser Klasse werden folgende Native-Methoden aus pilespace.cpp zugänglich:

1. public native void GetCoordinates(int hSpace, long v, Coordinates coords);
2. public native int Open();
3. public native long GetValue(int hSpace, long x, long y);
4. public native long SetValue(int hSpace, long x, long y, long v);
5. public native void Initialize(int hSpace, short nPartionBits);
6. public native void Close(int hSpace);
7. public native long FindValues(int hSpace, long xy, boolean isXCoordinate, long partitionFrom, long partitionUntil, ValueListItem ppHead)

Die Methode FreeValueListItems() wird dank Java und der GarbageCollection obsolet. Noch nicht implementierte aber exportierte Methoden wie Flush() habe ich ebenfalls nicht beachtet. Wie man sieht, habe ich mich möglichst an die Namen gehalten, die in der Datei pilespace.cpp verwendet werden. Der unsigned int wurde auf einen Java long gemappt. Problematisch waren die Rückgabewerte in C/C++, die als Pointer auf die Strukturen Coordinates und ValueListItem an die Methoden GetCoordinates() und FindValues() übergeben wurden. Aus diesen C-Strukturen (struct) wurden die Klassen Coordinates.java und ValueListItem.java. Diese beiden Javaklassen erhielten folgende Callback-Methoden, die ich aus dem C/C++-Kontext aufrufe, um die Werte an Java zurückzugeben:

Coordinates.setX()
Coordinates.setY()
ValueListItem.add()

Erzeugen der Headerdatei PileSpaceJNI.h

Diese Datei wird von javah aus der kompilierten Klasse PileSpaceJNI erzeugt. Diese Header-Datei ist notwendig, um die C/C++-Methoden an die JVM zu exportieren. Dies geschieht mit dem Aufruf

javah PileSpaceJNI

Implementieren von PileSpaceJNI.cpp

Diese Datei entspricht eigentlich der originalen pilespcace.cpp-Datei von Ralf. Im nächsten Schritt werde ich wahrscheinlich einen “sauberen” Wrapper bauen, indem ich die pilespace.dll von Ralf komplett “unangetastet” lasse und dann einfach zu meiner Wrapper-DLL hinzulinke. Man möge mir also auch bitte diese “Sauerei” verzeihen :-) Interessant sind hier die JNI-Aufrufe aus dem C-Kontext, um die Callbackmethoden aufzurufen.

Die DLL lässt sich mit MinGW problemlos mit folgendem Aufruf kompilieren:

g++ -Wall -D_JNI_IMPLEMENTATION_ -Wl,–kill-at -I/c/apps/dev/Java/jdk1.5.0_01/include -I/c/apps/dev/Java/jdk1.5.0_01/include/win32 -shared PileSpaceJNI.cpp -o PileSpaceJ
NI.dll

Starten und ausprobieren

In der PileSpaceINJ-Main-Methode() habe ich exemplarisch einen PileSpace geöffnet und erhalte das PileSpaceHandle hSpace mit dem ich die Methoden SetValue(), GetValue(), GetCoordinates() und FindValues() aufrufe. Analog dazu gibt es die datei test.cpp die dasselbe mit der originalen pilespace.dll auf purer C-Ebene vollzieht.

Die Java-Implementation ruft man einfach mit

java PileSpaceJNI

auf.

Alle Dateien findet ihr hier: PileSpaceJNI

Jetzt habe ich mich einfach entschieden mal mit einem JNI-Wrapper zu starten. Ich denke zwar die Übergabe der verketteten Liste wird noch Probleme bereiten, aber mal schauen !

Ich habe mich entschieden alles unter cygwin mit den GCC in der Version 3.4.4 zu realisieren. Nachdem ich den “Microsoft-C-Code” von Ralf für GCC angepasst habe ergeben sich aber leider nach wie vor einige Probleme, und zwar beim linken. Hier habe ich aber jetzt folgende Seite gefunden, und ich werde Mal schauen ob das weiterhilft:http://www.inonit.com/cygwin/jni/helloWorld/c.html. So wie es jedoch ausschaut, war es keine gute Idee GCC in der Version 3.4.4 mit cygwin zu nehmen, nachdem ich u.a. die jni_md.h angepasst habe. Hier war es z.B. notwendig das Fragment

typedef __int64 jlong;
durch long long jlong;

in der Headerdatei jni_md.h anzupassen.

Dann lies sich zwar mein erster JNI-Wrapper kompilieren, mit dem linken bzgl. Win32, JNI, DLLs hatte ich aber akute Probleme. Eine kurze Recherche im Netz und ein Feedback von Julian brachte mich auf MinGW. Ich bin mal gespannt. Sehr sympatisch erschien auch mit sofort der Abschnitt “How can a JNI DLL be created?” in den FAQs. Eigentlich genau das was ich brauche, oder? Schaun wir mal …

Ganz gut beraten für den Startup mit MinGW war ich mit http://www.mingw.org/MinGWiki/index.php/GettingStarted
Hier ein paar Links, die mir weitergeholfen haben:

1. JNI von der Zürcher Hochschule Winterthur THW
2. JavaWorld: JNI-Problem unter Java SE 5.0
3. JavaWorld: Enhance your Java application with Java Native Interface (JNI)
4. JNI-Tutorial

Tja, Projekte haben ja etwas Gutes. Losgelöst von der stark hierarchischen Struktur in einer Organisation, kann man in einer im Konzern eingebetten Projektstruktur sehr sehr effizient und effektiv arbeiten. Eigentlich laufen ja die meisten Unternehmungen in einem Konzern so ab. Die Vorteile einer Projektstruktur liegen auf der Hand: hierarchiefrei, dadurch schnelle Entscheidungsfindung und direkte Kommunikationswege von Jedem zu Jedem. Projekte kommen so zu schnelleren und besserern Ergebnissen als Unternehmungen mit starken hierarchischen Strukturen – deshalb implementiert man ja eben solche Projektstrukturen in großen Organisationen.

Was mir nur zunehmend auffällt sind die Probleme, die auftreten, wenn ein Projekt dem Ende zugeht. Konkret heisst dies, das die Projektstrukturen zum Teil wieder aufgelöst werden müssen. Das Projekt samt Strukturen wird assimiliert. Insbesondere bei IT-Projekten lässt sich hier oft gegen Ende des Projektes beobachten, das die Geschäftsprozesse des Konzerns nach und nach auf das Projekt übertragen werden müssen: ITIL, Incident- und Problem-Management-Prozesse, Change-Management-Prozesse usw. Je mehr beteiligte Einheiten, wie z.B. interne IT-Abteilung, externe Systemintegratoren und Dienstleister, Fachabteilungen desto komplizierter. Nicht selten endet dies in einer wahren Schlacht von Excellisten. Da wird ein und der selbe Fehler in 4 verschiedenen Excellisten gepflegt (einmal in der Excelliste der Fachabteilung, einmal in der Liste der internen IT-Abteilung, einmal in der offiziellen “Fehlertracking-Liste” nach Standard-Konzern-Prozess, einmal ….. ). Jeder in seiner eigenen persönlichen Excelliste, die der eigenen persönlichen Struktur entspricht und man ist tagelang damit beschäftigt, jene Excel-Listen zu synchronisieren.

Tja, so ist das eben! Eine super Lösung dafür habe ich noch nicht gefunden. Vielleicht wird es aber auch Zeit sich grundlegend über Organisationsstrukturen Gedanken zu machen? Würden große Organisationen auch ohne Standardprozesse funktionieren? Oder gar hierarchiefrei? Wenn ja, wie? Und wäre dies im Interesse heutiger Führungskräfte, Unternehmer, Vorstände? Fragen über Fragen. Vielleicht sollten wir aber auch klein anfangen. Ein Vordenker solcher völlig anderen Strukturen war Stafford Beer, der Management-Kybernetiker. Stafford Beer beschreibt in seinem Buch Beyond Dispute wie man anhand dreidimensionaler Körper, wie z.B. den Ikosaeder, Gruppen mit bis zu 30 Menschen und 12 Themen kybernetisch strukturieren kann. Die geschieht vollkommen hierarchiefrei. Das Buch beschreibt den dafür notwendigen organisatorischen Prozess für den Wissensaustausch. Mathematischen zeigt er auf, das nach drei Itterationsschritten dieses Prozesses bis zu 90% der Informationen ausgetauscht wurden. Das Ganze ist so vielversprechend, sodass es bereits als Produkt Syntegration® vom Malik Management Zentrum St. Gallen vermarktet wird. Ähnlich der Walt-Disney-Strategie, in der es drei Rollen gibt (Träumer, Realist, Kritiker) gibt es hier die Rollen “Bearbeiter”, “Kritiker” und “Beobachter”. Inspiriert wurde Stafford Beer damals von hyperstabilen Dreiecksstrukturen, die der Architekt Buckminster Fuller für seine Domes verwendet hatte. Aber zurück zur Ikosaeder-Struktur, welche auf 30 Teilnehmer und 12 Themen beschränkt ist. Vor einiger Zeit hatte ich die Idee, diese Struktur so zu erweitern, das sie auf größere Organisationen als Ganzes anwendbar wird. Dabei denke ich an einem dreidimensionalen Raum, in dem sich mehrere Ikosaeder befinden. Durch das hinzufügen einer weiteren Dimension, und zwar der Zeit und der Bewegung der Ikosaeder im Raum müsste es eigentlich machbar sein, das die Ikosaeder im Raum fliegen und sich von Zeit zu Zeit “treffen”. Über sogenannte

Kontaktpunkte der einzelnen Ikosaederstrukturen könnte dann das “Wissen¹ fließen”. Eigentlich müsste man diese Idee wirklich weiterspinnen !!!! Außerdem müsste man die Rolle von Pile evaluieren. Als ich kürzlich Ralf’s Papier “A Journey Into The Pile Universe” (Seite 45) las, war ich ganz überrascht darüber das ein PileSpace mit seinen Relationen nichts anderes als Dreiecksstrukturen speichert !!!! Eine Pile-Relation, hier die Relation AB=(A,B) bildet nichts anderes als eine Dreiecksstruktur ab. Der gerichtete Pfeil zwischen A und AB bezeichnet einen sog. “normativen Parent”. Die Verbindung mit dem Punkt zwichen AB und B beschreibt einen sog. “assoziativen Parent”. Leider weiss ich noch nicht wofür das gut ist. Bisher habe ich folgendes verstanden: Wenn wir einen Text ‘ABCDEFG’ hätten und diesen sequentiell von einer PileEngine assimilieren lassen würden, dann würde die Relation AB für die sog. Terminalvalues A und B bzw. Tops entstehen. Sowas, für was kategorisiert man eigentlich? Jetzt ist dieser Artikel doch in den Kategorien IT, Bücher, Kybernetik und PileSystems gelandet. Kann es wohlmöglich sein, das kybernetisch alles mit allem irgendwie verbunden ist ? :-)

Jetzt habe ich die grobe Architektur und die hauptächlich involvierten Quelltexte von Ralf gesichtet und teilweise verstanden. Das Problem: Ich habe noch nicht ganz die 2D-Abbildung bzw. deren Umsetzung durch Ralf’s Code verstanden. So hat z.B. die Struktur SpacePoint folgende Varialblen: coords, xPartners und yPartners. Ich vermute, das coords die x- und y-Koordinate des 2D-Handles enthält wie in Ralfs Papier beschrieben. Bei den xPartners vermute ich, das es sich um Handles für normative Parent-Relationen handelt. Bei den yPartners vermute ich, das es sich um die assoziativen Parent-Relationen handelt. Für mich gibt es jetzt drei weitere Vorgehensweisen

(1) Ich versuche stur, die C++-Implementierung und die C#-Implementierung 100% in Java zu übersetzen, ohne wirklich zu verstehen, wieso dies und das so und so funktioniert. Problem dabei wird sein, das es schwer nachzuvolziehen sein wird, ob die Umsetzung dann auch exakt das tut, was Ralfs Implementierung macht.

(2) Ich experimentiere selbst und baue eine eigene Java-Referenzimplementierung ohne mich allzustark an die C++/C#-Implementierung von Ralf zu lehnen. Das wird noch ein langer Weg sein :-)

(3) Ich versuche die Windows DLL der PileSpace-Kerns über das JavaNativeInterface (JNI) anzubinden, und setze erst die PileEngine, PileSpace, PileAgent in Java um.

Ich bilde mir einigermaßen ein, die Darstellung eines Piles in einer 2D-Struktur verstanden zu haben. Das größte Geheimnis ist für mich jedoch nach wie vor, wie man Daten aus Pile-Bäumen generieren lässt. Wie ich dem Quelltext wie auch dem Blog-Paper entnommen habe, ist ein großer Teil für die Generierung von Daten aus dem Pile im PileAgent für Fulltext-Search versteckt. Vermutlich steckt ein Geheimnis hinter den normativen und assoziativen Bäumen.

In Ralf’s Test steht:

• Following the path from parent to child relations along the normative manner defines a hierarchy, a context.
• Following th epath from child to parent along the associative manner links relations within a context with other contexts.

So ganz klar ist mir das, ehrlich gesagt, noch nicht.

Habe gerade mal mit JNI gespielt. Hierzu müsste ich einen C/C++-Wrapper bauen, der die Funktionen aus der pile.space.dll aufruft. Ein Blick in die Datei ImportCppPileSpace.cs verrät eine weitere “Sauerei”. Dort gibt es einen Pointer auf die Struktur ValueListItem, was nach einer einfach verketteten Liste aussieht. Hat jemand ne Ahnung wie man sowas über JNI an eine C-DLL weitergibt. Die zwei Funktionen FindVales(..) und FreeValuesListItems(…) benötigen diese verkettete Liste. Wo ist eigentlich die Doku zu deinem Quelltext, Ralf :-)

Mal schaun’ wie’s weiter geht. Ich saug’ mir erstmal den GCC für Win32. Mann, wie spannend, ist das lang her mit C/C++. Ich glaube das sind jetzt schon 10 Jahre her, das ich einen C-Compiler angefasst habe … ich werde alt ….

Am 05. Mai war das Meeting zwischen Peter, Gregor, Sedat und mir. Da habe ich mich wohl mal wieder übernommen, mit dem Satz: Ich mache mal eben die Java-Referenzimplementierung zu Pile. Das kann noch dauern. Denn ich habe die Pile-Relationsstruktur noch immer nicht vollständig verstanden. Ich bin aber jetzt erst auf die Seite http://www.pileworks.org aufmerksam geworden, nachdem ich Ralf’s “A Journey Into The Pile Universe” etwas genauer im ICE von Bonn nach Hamburg studiert habe.
Okay, was ist bisher passiert? Bisher habe ich das Papier von Ralf studiert, um ein wenig mehr von seiner Referenzimplementierung und über Pile selbst u lernen. Parallel dazu habe ich mir die Referenzimplementierung von Ralf Westphal heruntergeladen.

Dabei habe ich folgende Erkentnisse gewonnen:

1. Die Referenzimplementierung von Ralf ist nicht reines C# sondern ein C#-Wrapper, um einen PileSpace-Kern, der in C++ geschrieben ist. Puh hier muss ich meine alten C++ Erfahrungen aber wieder auspacken (was war noch gleich ne C-Map? Stimmt die stammt doch aus dem STLs (Standard Template Libraries – Wau ist das lange her, das waren Cyberdynezeiten, so 1998) Baue ich das in einen Java-Vector oder in eine Java-Map um? – mal sehen. Eine STL-Map hat eine .find()-Methode, wenn ich es richtig gesehen habe!
2. Da ich, wenn schon, denn schon, eine pure 100% Java-Variante bauen möchte, muss ich da noch einiges “umbauen” :-)
3. Der Pile-Architekur-Stack sieht also wie folgendes aus: C++ Kern, C#-PileSpace-Wrapper, darauf eine Pile-Engine, ein Pile-Agent und darauf ein Pile-Client (!)

Dabei haben die einzelnen Komponenten folgende Funktionen:

1. PileSpace: Der PileSpace ist die low-level-Komponente des PileSystems. Der PileSpace bildet SpacePoints ab, welches Punkte in einer 2D-Struktur sind um Relationen zu speichern (Hierzu werden eindeutige Handles verwendet die durch Integer abgebildet werden). Details findet man in Ralfs Paper.
2. PileEngine: Die PileEnginge liegt oberhalb des Pile-Spaces im Architekturmodell. Die Pile-Engine delegiert an den PileSpace-Layer, operiert aber ebenfalls noch mit Terminal-Values und hält Informationen über Child- und Parent-Elemente vor.
3. PileAgent: Der Pile-Agent liegt im Architekturmodell oberhalb der Pile-Engine und implementiert eine Pileanwendung aus fachlicher (business) Sicht.
4. PileClient: Die genaue Abgrenzung zwischen PileAgent und PileClient ist mir noch unklar. Vermutlich ist der PileClient einfach eine weitere Abstraktion, stellt vielleicht die Oberfläche einer Pile-Anwendung dar!???

Der Kern der Demo besteht aus folgender Datei:

pilespace.cpp

1. beinhaltet die Struktur SpacePoint, welche einfach eine 2D-Koordinate abbildet, um eine Pile-Relation zu beschreiben, wie in Ralfs Blog beschrieben. Wahrscheinlich wird dies eine Java-Klasse, was sonst :-) ?. Dies wird durch die Struktur Coordinates coords realisiert. Was mit nicht ganz klar ist, ob es ein Variable gibt, um zu erkennen, in welchem Quadranten der SpacePoint lokalisiert ist. Aus dem Quadranten (siehe Seite 38 in dem PDF-Summary von RalfW) ergibt sich ja auch die Art der Relation (Np, Top) (Top,Top), (Top, Ap), (Np, Ap). Die Crux liegt vermutlich in einer Struktur namens PartnersDictionary deren Ausprägung xPartners und yPartners heissen. Diesses PartnersDictionary ist selbst wieder eine Map aus zwei “unsigned integern”, vermutlich benutzt Ralf diese Struktur, wenn ein SpacePoint selbst als Koordinate von anderen SpacePoints verwendet wird. Die Geschichte mit der Diagonalen indem Koordinatensystem ist mir aber noch nicht ganz klar.
2. beinhaltet eine Liste bzw. Map von SpacePoints, welche PointsDictionary heisst. vermutlich implementiere ich diese Map als Javaklasse, die ich von einer Java-Map oder einem Vector ableite.
3. beinhaltet die Struktur PileSpace, welche ich vermutlich ebenfalls als Java-Klasse implementieren werde. Ein PileSpace beinhaltet nichts anderes als eine Map von SpacePoints.
4. Das PileSpaceDirectory ist wieder eine Map von PileSpaces und verwandelt diese. Ich bin verleitet hier das Factory-Pattern anzuwendenSehr knifflig werden hier die Methoden setValue() und getValue(), da man hier die 2D-Abbildung der Relationen sehr wohl verstanden haben muss. Ich habe gelernt, das man zwischen folgenden Dingen beachten muss:
   • Die Datenatome werden niemals innerhalb der Pilestruktur gespeichert, so wie wir Dinge unserer Umwelt, z.B. das nicht in unser Gehirn rein-tun. Das da draußen bzw. der Buchstabe ‘H’ bleibt draußen. In der Pile-Terminologie wird dies als TerminalValue (Tv) bezeichnet.
   • Natürlich muss es so etwas wie ein “Mapping” geben. Dieses Mapping wird durch die sogenannten Tops realisiert. Eine Tv:Top Beziehung, ist, wie ich es im Moment verstehe immer eine 1:1-Beziehung und bidirektional.
   • Dann gibt es die System Definer (SD). Deren Zweck habe ich noch nicht verstanden, weil ich noch nicht weiss was es genau mit dem normativen Tree unddem assoziativen Tree auf sich hat. Ein SD ist, wenn ich es richtig verstanden habe, immer eine Relation zwischen Tops
   • Weiterhin gibt es normative und assoziative Roots. Normative Roots bilden Relationen zwischen einem normativen Parent und einem Top ab (Np, Top). Assoziative Roots bilden Relationen zwischen einem assoziativen Parent und einem Top ab.last but not least gibt es Relationen zwischen assoziativen Parents und normativen Parents (Np, Ap)

So, die anderen drei Quelltexte, die aus meiner Sicht eine wesentliche Rolle spielen, nehme ich mir das nächste Mal vor: PileSpace.cs, PileEngine.cs, PileAgent.cs.

Au, da fällt mir ein, Ralf wollte noch einen komplexen Graphen, bei der sich meine Modeller-Software die Zähne ausbeisst, wenn Sie nach Zyklen mit einer einfachen Tiefen- und Breitensuche an das Problem rangeht. Wie verhält sich eine PileEngine, wenn man Zyklen in einem komplexen Graphen mit hoher Dichte sucht. Fragen über Fragen. Also Ralf, ich hab’s nicht vergessen. Wochenends ist eben meist Famillybusiness angesagt und das kommende Wochenende ist auch schon wieder in Bonn verplant.