Ausgangslage: Theorie mit zwei Größen und dazu ein Regelschema (als minimale Theorie)
In der Theorie T-brunnen-einw-v1 hatten wir schon die Größen Brunnenkapazität und Einwohnerzahl eingebaut. Es gab nur noch keine explizite Verbindung. In der Theorie T-brunnen-einw-prokopf-v1 hatten wir schon eine Lösung per Hand konstruiert. Jetzt probieren wir eine Vereinigung von T-brunnen-einw-v1 mit unserer neuen minimalen Theorie mit Regelschema T-empty-pro-Kopf.
Wir vereinigen diese beiden Theorien zur neuen Theorie MTT-brunnen-einw-pro-Kopf:
Wir können sofort erkennen, dass die Größe ‚K‘ der Größe ‚BrunnenHellerborn‘ entspricht und die Größe ‚B‘ der Größe ‚Einw‘. Die restlichen Größen ‚Uhr‘ und ‚Abnahme‘ brauchen wir nicht mehr.
Von den drei Regeln müssen nur zwei Regeln verändert werden:
In dieser Regel werden die beiden Größen BrunnenHellerborn und Einw zueinander in Beziehung gebracht. Die Größe FlagAB dient weiter zur Aktivierung (=1) und zur Deaktivierung (=0) dieser Regel.
Hier wurde für die Regel mit der Brunnenkapazität noch eine Formatierung für die Dezimalzahlen ein gefügt, um auf 2 Stellen nach dem Dezimalpunkt zu begrenzen.
Die Simulation erbringt folgenden Wertverlauf (Zum selber Simulieren bitte hier klicken):
Dies sind die gleichen Zahlen wie in der anderen Version.
Die Grafik für die Brunnenkapazität und die Einwohnerzahl zeigt das folgende:
Die Grafik für den ProKopf-Verbrauch zeigt dieses:
In dem Beitrag Nachhaltige Empirische Theorie und die oksimo Software wird schematisch beschrieben, was im Kontext der oksimo Software als ’nachhaltige empirische Theorie (NET)‘ verstanden wird und wie das Konzept einer NET innerhalb der oksimo Software umgesetzt wird.
Innerhalb der oksimo Software steht für eine NET folgendes Schema zur Verfügung:
Die wichtigen Elemente sind:
Name
Visions (Ziele)
States (Zustände)
Rules (Veränderungsregeln)
Veränderungsregeln beziehen sich in der Regel auf eine konkrete Situation (Zustand) und verändern spezifische Eigenschaften. Es gibt aber auch Veränderungen, die eine recht allgemeine Struktur beschreiben, die sich auf viele Einzelfälle anwenden lässt. So z.B. die Aufteilung einer Größe wie ‚Menge verfügbaren Trinkwassers‘ auf die ‚Menge von aktuellen Einwohnern‘. Weiter konkretisiert: ‚Menge verfügbaren Trinkwassers in m3‚ auf die ‚Menge von aktuellen Einwohnern‘ umgelegt auf ‚pro Tag und gemessen in Liter‘.
Es liegt nahe, dafür eine kleine Theorie zu machen, die solch eine Aufteilung realisiert und die man dann — das ist der Plan — nach Bedarf mit anderen Theorien vereinheitlicht, in denen zwei Größen vorkommen, die genau solch eine Aufteilung brnötigen.
Kleine Modelltheorie für Aufteilung
Hier die Basis der Theorie (Name, Visions, States):
Wichtig sind hier die Grundgrößen K für eine Kapazität (Wert unwichtig) und B für Verteiler (Wert unwichtig). Die Größen ‚ProKopf‘, ‚Uhr‘ und ‚Abnahme‘ sind ‚Dummies; sie werden hier nur gebraucht, um die Theorie überhaupt zum Laufen zu bringen. Die Größe ‚FlagAB‘ dient dazu, nach einem Zustand der Deaktivierung ‚FlagAB=0‘ in einen Zustand der Aktivierung ‚FlagAB=1‘ zu versetzen.
Diese Regel dient nur dazu, die Größe FlagAB von =0 auf =1 zu setzen, damit die eigentliche Verrechnung aktiviert werden kann.
Wenn die Größe FlagAB auf =1 gesetzt ist, dann tritt die Regel ProKopf=… in Aktion. Der Ausdruck K=K-(K*Abnahme) ist nicht wirklich notwendig. Sie hilft hier nur zur Veranschaulichung, um die Veränderung der Größe ProKopf sichtbar zu machen. Der Ausdruck FlagAB=0 nimmt die Aktivierung dann wieder zurück.
Startet man die Simulation, kann man folgenden Wertverlauf sehen (Man kann diese Simulationen selber hier ausführen):
Die verfügbare Kapazität verringert sich und davon abhängig der ProKop-Verbrauch.
Im Grafen kann man folgendes sehen:
Und:
Auf den ersten Blick funktioniert die kleine Theorie mit veränderlicher Verteilung bei fester Abnahmemenge. Fragt sich, ob diese Idee auch beim Vereinigen mit einer anderen Theorie funktioniert.
Fallbeispiel: es liegen schon zwei fertige Theorien vor:
T-brunnenkapazität-verlauf-v1 (Nennen wir gleich nur noch T1-brunnen)
T-einwohner-verlauf-v1 (Nennen wir gleich nur noch T2-einwohner)
Diese beiden Theorien sind schon einmal zusammen geführt worden, indem (i) eine Kopie von der Theorie T1-brunnen erstellt worden ist und (ii) in diese Theorie wurde dann per Hand der Text der Theorie T2-einwohner eingetragen. Daraus wurde dann T-brunnen-einw-v1.
Wie man sieht, kann man dies machen, aber es ist schon ein wenig aufwendig. Und je umfangreicher der Text zu einer Theorie wird, um so aufwendiger wird dies. Schöner wäre es, man kann ‚per Knopfdruck‘ zwei Theorien T1 und T2 zu einer vereinigen (mergen). Mit dr oksimo Software geht dies.
Vereinigung per Klick …
Dazu wählt man die Theorie T1 aus (= T-brunnenkapazität-verlauf-v1) und sagt (als Autor), dass man diese Theorie mit einer anderen Theorie T2 (= T-einwohner-verlauf-v1) aus der Liste der verfügbaren Theorien vereinigen will.
Für die weitere Arbeit verkürzen wir den Namen T-brunnenkapazität-verlauf-v1_T-einwohner-verlauf-v1_1706607593 ein wenig:
Dann schauen wir uns an, wie die vereinigte Theorie arbeitet, indem wir für die neue vereinigte Theorie eine Simulation aktivieren.
Wenn man sich dann die Tabelle der mathematischen Größen anschaut, kann man Folgendes feststellen:
Alle Werte sind wie es die Einzeltheorien erwarten lassen und wie es auch die ‚per Hand vereinigte Theorie angezeigt hat. Bis auf einen Wert, der auffällt: Die Jahreszahlen weisen Sprünge von +2 auf statt +1.
Wenn man genauer hinschaut, dann sieht man, dass die Größe ‚Jahr‘ zweimal vorkommt! Einmal als Teil der ursprünglichen Theorie T1 und einmal als Teil der ursprünglichen Theorie T2. Dies bedeutet, dass die Anweisung, die Jahreszahl um +1 zu erhöhen, zweimal pro Runde ausgeführt werden wird:
In der aktuellen Version der Software ist der einfachste Weg, um diese ‚Verdopplung‘ zu beseitigen, ein Vorkommnis der Anweisung ‚Jahr=Jahr+1‘ einfach zu löschen.
Die neue Version der vereinigten Theorie mit nur einem Vorkommnis der Größe Jahr sieht dann wie folgt aus:
Die Jahreszahlen zeigen eine lineare Steigerung von durchgehend +1 an. Damit stimmen alle Werte dieser vereinigten Theorie mit jenen der zuvor manuell vereinigten Theorie überein.
Auch die Überprüfung der Regelanwendung während der Simulation ergibt, dass die Anweisung ‚Jahr=Jahr+1‘ nur noch einmal pro Runde angewendet wird.
(Um die Simulation selbst überprüfen zu können können Sie auf die Seite der ‚Public Theories‘ der oksimo Software gehen: https://oksimo.com/public_theories
Damit sieht man, dass bei der Vereinigung von zwei bestehenden Theorien bestimmte Variablen doppelt vorkommen können. Diese Doppelung muss man beseitigen.
Sofern diese Doppelungen Größen betreffen, die gleichlautend sind, kann man alle Doubletten einfach weg-löschen. Sollten gleiche Namen vorkommen, die mit unterschiedlichen Ausführungen verknüpft sind, dann muss man Umbenennungen vornehmen und die Wechselbeziehung mit anderen Ausdrücken berücksichtigen.
Generell sollte man aber beim Schreiben einer Theorie aber niemals die gleichen Namen mit unterschiedlichen Ausführungen verwenden, da dies im Normalfall immer zu Konflikten führen wird.
/* Es gibt jetzt auch eine Englische Version: Diese entsteht dadurch, dass man die deutschen Texte durch englischen Texte ersetzt. Alles andere bleibt gleich. Wer will, kann sich dies auf der oksimo Software Seite anschauen, siehe: https://oksimo.com/public_theories :
Zugang zur Simulation
In diesem Beispiel wird eine erste kleine Theorie entwickelt und getestet. Dazu wird das oksimo Interface auf der Seite https://oksimo.com benutzt. Bis auf weiteres ist der direkte Zugang nur für registrierte Benutzer möglich. Die graphische Benutzerschnittstelle (GUI) enthält noch einige Fehler und muss noch eine Weile getestet werden. Im folgenden — und weiteren — Beispielen kann man aber schon mal sehen, wie die Software arbeitet. Wer will, kann über die öffentliche Schnittstelle https://oksimo.com/public_theories dieses Theoriebeispiel aufrufen und selbst testen.
Es erscheint dann ein Pop-Up Menü, bei dem man die gewünschte Zahl der Simulationsrunden angeben kann (es reichen 6) und wie detailliert der Output sein soll. Ohne Häkchen sieht man den normalen Simulationslauf, mit Häkchen sieht man, welche Veränderungsregeln in jeder Runde angewendet worden sind. Letzteres kann sehr aufschlussreich sein, wenn man Verstehen will (Transparenz, Vertrauen, …!) , wie das Ergebnis zustande kommt.
Theorie und Software
Wie schon im Abschnitt Nachhaltige Empirische Theorie und die oksimo Software schematisch beschrieben worden ist, gibt es eine direkte strukturelle Entsprechung zwischen dem Konzept einer nachhaltigen empirischen Theorie (NET) und der oksimo Software. Dies wird in dem nachfolgenden Schaubild nochmals verdeutlicht.
BILD : Beziehung zwischen dem Schema einer nachhaltigen empirischen Theorie und dem Schema des oksimo Editors.
Am Beispiel der kleinen Demo-Theorie T-gerd-hungrig-v2d soll dies hier in einzelnen Schritten gezeigt werden.
Idee von T-gerd-hungrig-v2d
Die Demo-Theorie T-gerd-hungrig-v2d besitzt alle Elemente, die man im Rahmen der oksimo Software benutzen kann. Deren Verwendung wird am Beispiel der Geschichte von der Person Gerd illustriert, die hungrig ist, und den Wunsch (= das Ziel, die Vision) hat, nicht mehr hungrig zu sein. Dazu entscheidet sich Gerd, in ein nahe gelegenes griechisches Bistro zu gehen, dort etwas zu essen, um so seinen Hunger zu stillen.
Normalerweise würde niemand in solch einem Fall von einer ‚Theorie‘ sprechen, erst Recht nicht von einer ’nachhaltigen empirischen Theorie‘, aber die Beschreibung dieses Vorgangs kann sehr wohl im Format einer nachhaltigen empirischen Theorie vorgenommen werden. Dies liegt daran, dass man den Vorgang mit folgenden Elementen konstruieren kann:
Es gibt einen Ausgangszustand, ein IST-Zustand, den man beschreiben kann.
Es gibt eine Reihe von Veränderungsregeln (Regeln, Rules), die man auf die Ausgangssituation anwenden kann, um nachfolgende Zuständegenerieren (ableiten) zu können.
Die Anwendung von Veränderungsregeln auf einen gegebenen Zustand wird durch den Simulator (der einen Folgerungsbegriff realisiert) vorgenommen.
Sofern ein Ziel (Vision) vorgegeben wurde, kann man bei jedem Folgezustand nachschauen, ob und wie viel dieser mit dem Ziel übereinstimmt. Im Idealfall können dies 100% sein.
Wer nachdenkt wird feststellen, dass dieses Schema auf fast alles anwendbar ist, was wir im Alltag erleben. Dies liegt daran, dass der Alltag sich letztlich aus ganz vielen Prozessen zusammensetzt, die alle zusammen genommen einen großen Prozess bilden, in dem sich die jeweilige ‚Fortsetzung‘ (Zukunft) formt. Insbesondere sind alle Spiele als nachhaltige empirische Theorien rekonstruierbar, jede Theateraufführung, und vieles mehr.
Der Theorie-Kopf
Beim Editieren einer Theorie kann man einen Namen vergeben (T-gerd-hungrig-v2d) und eine kurze Beschreibung (Description) verfassen. Das Format der Beschreibung ist frei.
Die Vision (das Ziel)
Eine Vision (ein Ziel) kann man angeben, muss es aber nicht. Ohne ein explizites Ziel kann man untersuchen, welche Folgen sich aus einem Anfangszustand ergeben können. Dies kann man entweder einfach als ‚Gedankenexperiment‘ sehen (Roman, Drehbuch, Spiel, Vorwegnahme eines echten Experiments, …) oder als Versuch, mit bekannten empirischen Daten mögliche empirische Szenarien durch zu spielen.
Mit einem expliziten Ziel (dem Mut zu einer Vision) eröffnet sich die Möglichkeit, einen skizzierten Ablauf darauf hin explizit zu prüfen, ob und wie der geplante Ablauf tatsächlich das gegebene Ziel erreicht. Dies ermöglicht also eine ganz neue Transparenz bei dem Versuch, bestimmte Ziele zu erreichen.
Text und Mathematik
Wie man schon zu Beginn bei der Vorstellung der möglichen Vision einer nachhaltigen Theorie erkennt, wird in der oksimo Software zwischen Text und Mathematik unterschieden. Man kann entweder nur mit Text arbeiten oder nur mit Mathematik oder mit einer Kombination von beidem.
Das Motiv hinter dieser Unterscheidung liegt in Folgendem:
Aus Sicht einer Theorie ist auch die Mathematik in erster Linie eine Sprache (!), wenngleich eine spezielle Sprache.
Im Rahmen unserer Alltagssprache können wir mathematische Sprache einbauen oder nicht. Im Prinzip kann man alles ohne die Benutzung der mathematischen Sprache benutzen.
Es gibt aber viele Fälle, da bietet die mathematische Sprache Ausdrucksmöglichkeiten, die extrem hilfreich sind; auf diese freiwillig zu verzichten wäre irgendwie ‚blöd‘. Wenn man z.B. Einkaufen will und dürfte keine mathematischen Ausdrücke benutzen, dann hätte man große Probleme (z.B. wie viel will man von was; wie viel kostet etwas; …). Der Alltag ist voll von Situationen, in denen man mathematische Ausdrücke braucht, um schnell klar zu kommen. Ein anderes Beispiel ist die Zeit. Wenn man nur ‚morgens‘, ‚mittags‘ oder ‚abends‘ sagen kann, ist dies für viele Absprachen (Koordinierungen) zu wenig. Dazu wurden ja Maschinen erfunden, die wie Uhren nennen, und diese Uhren erlauben Zeitangaben, die wir mit mathematischer Sprache ausdrücken (z.B. 12:00h oder 4 Uhr nachmittags oder …)
In der oksimo Programmiersprache kann man die Vorteile beider Arten von Sprache benutzen und kombinieren.
Im Fall der Vision wird nur die normale Sprache benutzt. Der Ausdruck „Gerd ist nicht hungrig.“ ist in Alltagssprache formuliert; die meisten dürften diesen Ausdruck verstehen. Dieser Ausdruck beschreibt einen Sachverhalt, in dem eine Person (hier: Gerd) nicht hungrig ist. Da dieser Ausdruck als Vision (Ziel) eingeführt wird, bedeutet dies, dass diese Theorie einen möglichen Prozess untersucht, der in einem möglichen zukünftigen Zustand endet, in dem der Gerd eben nicht hungrig ist.
Zustände
Der Abschnitt States beschreibt hier den Anfangszustand eines Prozesses, mit dem man sich in der Theorie beschäftigen will. Dieser Anfangszustand kann entweder rein erfunden sein, also fiktiv, oder aber er kann eine echte reale Situation beschreiben. Dabei kann jede Beschreibung einer Situation die erst fiktiv ist, irgendwann auch mal real sein, und umgekehrt. Wenn z.B. in einer Situation jemand sagt „Es regnet“ (weil es gerade regnet), dann trifft diese Beschreibung empirisch zu. Wenn diese Beschreibung aufgeschrieben wird, mit Uhrzeit, dann kann es sein, dass die Beschreibung wenige Minuten später schon nicht mehr zutrifft, und umgekehrt: Jemand sagt in sein Handy, dass es hier gerade nicht regnen würde, und im nächsten Moment fängt es an zu regnen.
Hier wird die alltagssprachliche Beschreibung (Text) noch um einen mathematischen Ausdruck ergänzt: „Zeit=12Uhr“. Es handelt sich hier um einen Ausdruck der mathematischen Sprache, bei dem der Name einer Größe (hier ‚Zeit‘) mittels des Gleichheitszeichens ‚=‘ einen Wert (’12‘) zugewiesen bekommt. Zusätzlich wird dem numerischen Wert ’12‘ noch eine Einheit (‚Uhr‘) hinzugefügt. Welche Einheiten man numerischen Werten hinzu fügt ist in der oksimo Sprache beliebig. Hier wird mit dem mathematischen Ausdruck „Zeit=12Uhr“ nur gesagt, dass der Zustand von Gerd, dass er hungrig sei, stattfindet während die Größe ‚Zeit‘ den Wert ’12Uhr‘ hat.
Veränderungsregeln (‚Rules‘)
BILD : Liste von verschiedenen Veränderungsregeln (‚Rules‘)
Nach Vorgabe eines Anfangszustands und eines — optionalen — Ziels braucht man jetzt Veränderungsregeln, um aus einem Anfangszustand so viele Folge-Zustände generieren zu können, dass man den vorgegebenen Ziel-Zustand entweder zu 100% erreicht oder ihn zumindest so weit annähert, dass alle Beteiligten zufrieden sind. Wie viele Regeln dazu notwendig sind, dies kann man nur durch Ausprobieren heraus bekommen. Im vorliegenden Beispiel sind es sechs Regeln. Beim Durchlaufen der Regeln wird man leicht erkennen, dass die Anzahl der benötigten Regeln letztlich davon abhängt, wie genau, mit welcher Detailtiefe, man einen Prozess beschreiben will. Im Prinzip kann man immer mit einer einzigen Regel auskommen, aber dann versteht man normalerweise nicht, wie dies in der Realität möglich ist. Anders formuliert, je wirklichkeitsnäher man einen Prozess beschreiben will, umso mehr Regeln wird man benötigen.
Im vorliegenden Beispiel gibt es eine hinreichende Nähe zu einem möglichen Alltag, die so groß ist, dass normalerweise jeder sich vorstellen kann, was genau passiert, wenn man diese Theorie im Alltag umsetzen wollte.
BILD : Elemente der ersten Veränderungsregel mit Namen ‚gerd-v-2-1‘
Regel Typen
Als erstes kann man erkennen, dass es tatsächlich zwei Arten von Regeln gibt: (i) Regeln, die Zustände (‚States‘) verändern können und (ii) solche, die Visionenverändern können.
Im vorliegenden Beispiel kommen nur Regeln vor, die Zustände verändern. Das Ändern von Visionen (Zielen) ist allerdings interessant, weil es im Alltag ständig passieren kann, dass Menschen ihre Ziele ändern. Dies kann aus unterschiedlichen Gründen geschehen. In weiteren Beispielen wird dieser Fall vorgestellt werden.
Bedingungen (‚Conditions‘)
Regeln sind so aufgebaut, dass sie sich an Bedingungen festmachen: Irgendein Effekt (eine Wirkung) soll nur dann eintreten, wenn ein bestimmter Sachverhalt vorliegt (ein Schneepflug sollte sinnvollerweise nur dann ausrücken, wenn tatsächlich Schnee gefallen ist; einen Feuerlöscher sollte man normalerweise nur aktivieren, wenn etwas zu brennen angefangen hat; …)
Im vorliegenden Beispiel soll die Regel nur angewendet werden, wenn im Textteil der Ausdruck vorkommt Gerd ist hungrig. und im mathematischen Teil der Ausdruck Zeit==12 ‚wahr‘ ist, weil der Wert der Größe Zeit tatsächlich gerade 12 ist. Werden diese Bedingungen nicht erfüllt, dann wird die Regel nicht aktiviert. Mit anderen Worten, die Theorie T-gerd-hungrig-v2d nimmt an, dass der Zeitpunkt 12:00 für die Person Gerd wichtig ist (kann in der Realität falsch sein).
Wirkungen (‚Effects‘)
Sollten beide Forderungen erfüllt sein, so dass die Regel aktiviert werden, dann kämen diese zur Ausführung. Dies bedeutet, im Textteil des Folge-Zustandes würde als neuer Ausdruck Gerd entscheidet, zum Griechen um die Ecke zu gehen. hinzugefügt werden, und der Wert der Größe Zeit würde um den Wert 0.03 erhöht werden zu 12.03.
Der mathematische Ausdruck Zeit=eval(„{:.2f}“.format(Zeit+0.03)) wirkt dabei auf den ersten Blick etwas wild. Obwohl es hier um einen ganz simplen Sachverhalt geht, nämlich um die Erhöhung der Zeit 12 Uhr um 3 Minuten auf 12.03 Uhr und man dies einfach so ausdrücken könnte: Zeit = Zeit + 0.03 wird hier zu diesem etwas wilden Ausdruck gegriffen. Warum?
Die mathematische Sprache, die in der oksimo Software benutzt wird, ist eine Teilmenge der Programmiersprache python. Und wie jede Programmiersprache so hat auch python seine eigenen Regeln, wie man was hinschreiben muss. Hier ein kurzes Beispiel zum Thema 12+0.03:
Zeit=12 Zeit 12 Zeit=Zeit+0.03 Zeit 12.03 Zeit=Zeit+0.04 Zeit 12.069999999999999
Dieser kurze Text zeigt, was passiert, wenn man in der Programmiersprache python (version 3.10.12) 12+0.03 addiert (dann kommt brav 12.03 heraus), aber wenn man dann eine Dezimalversion weiter addiert, also 12.03+0.04, dann bekommt man furchtbar viele Stellen hinter dem Komma: 12.069999999999999 . Will man dies verhindern (und das wollen wir in diesem Beispiel), dann könnte man standardmäßig folgende python-Operation benutzen: round():
Zeit 12.069999999999999 Zeit=round(Zeit,2) Zeit 12.07
In der aktuellen Version der oksimo Software haben wir allerdings nur einen Teil der python Programmiersprache zugelassen. Die Operation round() ist aktuell nicht dabei. Vermutlich kommt sie später noch dazu. Was kann man aber ohne diese Operation round() machen?
In python gibt es ja nahezu für alles eine Lösung, oft sogar mehrere Varianten. Die andere Variante ist jene, die im Beispiel tatsächlich benutzt wurde: Zeit=eval(„{:.2f}“.format(Zeit+0.03))
Dieser Ausdruck besteht praktisch aus drei Teilen:
Zeit+0.03 : das ist die eigentliche Operation um die es geht; erhöhe die aktuelle Zeit um 3 Minuten.
{:.2f}“.format(x) : die Dezimalzahl x soll in eine Zeichenkette (’string‘) verwandelt werden und diese Zeichenkette soll als Dezimalzahl (‚float‘) mit zwei Nachkommastellen formatiert werden. Man würde dann die Zeichenkette ‚12.03‘ erhalten. Zeichenketten sind aber nun mal keine Zahlen, mit denen man rechnen kann. Also muss man diese Zeichenkette wieder zurück in eine Zahl verwandeln:
eval(…) : Man packt dazu den ganzen Ausdruck, der eine Zeichenkette erzeugt, als Argument in die Operation eval() und diese Operation erzeugt uns wieder eine Dezimalzahl, dieses Mal aber mit zwei Nachkommastellen: 12.03.
Zugegeben, etwas umständlich, aber es funktioniert und man hat gegenüber der Operation round() den Vorteil, dass man mit der Stringmethode viel mehr Formatierungsmöglichkeiten hat als mit der Operation round().
Zur Beruhigung: solange man nicht zwischen verschiedenen Objektformaten hin und her transformieren muss, sind die mathematischen Ausdrücke eigentlich ‚intuitiv‘ (wer versteht 12+0.03 nicht?).
Überprüfung durch eine Simulation
Bevor wir hier jetzt die weiteren Veränderungsregeln vorstellen, können wir schon die bisherige Theorie T-gerd-hungrig-2vd mit dieser einen Regel testen. Dazu kann man auf die Seite des oksimo Editors und Simulators gehen https://oksimo.com/public_theories und den Button Public Theories drücken:
Dort findet man die kleine Theorie T-gerd-hungrig-2vd schon aufgelistet. Wenn man diese anklickt, erweitert sich die Anzeige:
Es gibt die Option, die Theorie zu simulieren. Das wollen wir jetzt mal tun. Wenn man auf Simulate klickt erhält man eine weitere Auswahlmöglichkeit:
Gibt man als Wert = 1 ein (also eine Runde simulieren) und aktiviert man den detaillierten Output nicht, dann erhält man Folgendes:
Man bekommt alles aufgelistet, was bislang eingegeben worden ist, allerdings ohne die Regel. Man sieht aber dann bei Aktueller Zustand (‚Current State‘), dass die Wirkung der ersten Regel gerd-v-2-1 in den Folgezustand eingearbeitet worden ist. Und da die Vision ‚Gerd ist nicht hungrig‘ im aktuellen Zustand noch nicht vorkommt, liegt die Zielerreichung noch bei 0%.
Vervollständigung der Theorie
Mit den vorausgehenden Erklärungen sollte es möglich sein, dass jeder Leser nur durch Angabe der weiteren Regeln versteht, was hier beschrieben wird. Zum Abschluss kann jeder dann selbst die Gesamt-Simulation online anschauen.
An dieser Stelle ist noch ein zusätzlicher Kommentar notwendig, da in dieser Regel gerd-v-2-2 erstmalig eine Regel mit einem negativen Effekt auftritt. ‚Negativer Effekt‘ bedeutet, dass die sprachlichen Ausdrücke, die im Feld Negative Effekte (‚Negative Effects‘) vorkommen, aus dem aktuellen Zustand wieder entfernt werden, so dass sie im Folge-Zustand nicht mehr vorkommen. Im Zusammenwirken von Positiven und Negativen Effekten kann also die Menge der sprachlichen Ausdrücke, die einen Zustand ausmachen, kontinuierlich modifiziert werden. Damit lässt sich im Prinzip jede Art von Dynamik modellieren. Die Umsetzung dieser ‚Anweisungen‘ zum ‚Hinzufügen‚ oder zum ‚Entfernen‘ von Ausdrücken geschieht im Simulator, der hier als ‚Folgerungs-Maschine‘ wirkt.
Hier geht es zum online-Simulator ( https://oksimo.com/public_theories ). Die optimale Einstellung für die Simulation ist: Rundenzahl 6 und Detailierter Output aktiv.
Hier kann man dann auch von einer grafischen Ausgabe des Werteverlaus Gebrauch machen:
