OKSIMO EINFACHE BEISPIELE – Bsp.: Schlafmöglichkeiten, Verzweigung

OKSIMO – Universelle Prozessplanung

E-Mail: info@oksimo.org

Autorin: Athene Sorokowski, E-Mail: athene@oksimo.org

Veröffentlicht: 04.06.2021

KONTEXT

Dieses Fallbeispiel gehört zur Sektion Einfache Beispiele des Blogs oksimo.org.

Fallbeispiel Beschreibung:

Im Folgenden sind die Zustände, Regeln und die Vision eines Fallbeispiels der oksimo-Software dokumentiert, welches sich darauf fokussiert, sogenannte „Verzweigungen“ zu realisieren. Um die Vision im Beispiel zu erreichen, wurden verschiedene Veränderungsregeln erstellt, denen wiederum verschiedene Wahrscheinlichkeiten zugeordnet wurden. Die unterschiedlichen Zweige teilen sich auf in „Gruppenraum“ und „Nachhause“. Die Akteurin im Beispiel, Francesca, hat die Wahl, ob sie sich im Gruppenraum ihrer Universität oder bei sich Zuhause schlafen legen will. Erstere Möglichkeit beträgt dabei eine Wahrscheinlichkeit von 0,6, letztere eine Wahrscheinlichkeit von 0,4. Das Ziel ihrer Entscheidungen, bzw. das der Veränderungsregeln, ist, dass sie nicht müde ist.

Fallbeispiel „Verzweigungen“

Wie funktionieren Verzweigungen?

Verzweigungen sind im oksimo Paradigma ausdrückbar durch das zur Verfügung stellen von mehr als einer Veränderungsregel. Ist die Wahrscheinlichkeit im Einzelfall <=1, dann wird für jeden Wahrscheinlichkeitswert ‚ausgewürfelt‚, was geschieht. Einfach gesprochen: bei einer Wahrscheinlichkeit von π=0.6 würde bei 100 Durchläufen ungefähr +/- 60 mal diese Option gewählt werden, entsprechend bei π= 0.4 ungefähr +/- 40 mal.

OKSIMO EINFACHE BEISPIELE: Bsp.: Jemand ist hungrig, Teil 4, Verzweigung

OKSIMO – UNIVERSELLE PROZESS PLANUNG
Veröffentlicht: 17.April 2021 – 7.Mai 2021
Email: info@oksimo.org

Autor: Gerd Doeben-Henisch; Email: gerd@oksimo.org

Letzte Änderung: 23.April 2021 (Kleine Korrekturen)

Letzte Änderung: 7.Mai 2021 (Neue Dokumentation, ausführlicher)

Letzte Änderung: 15.Mai 2021 (Verlinkung auf universelle Prozesse planen)

KONTEXT

Dieses Fallbeispiel gehört zur Sektion Einfache Beispiele des Blogs oksimo.org. Später wurde die Sektion universelle Prozesse planen geschaffen mit dem Fokus auf strukturelle Eigenschaften der oksimo Sprache. Das nachfolgende Beispiel würde auch in diese Sektion passen.

Beispiel: Jemand ist hungrig, Teil 4, Verzweigung

Dieses Beispiel ist eine Erweiterung des vorausgehenden Beispiels. Es geht auf den Sachverhalt ein, dass wir im Alltag sehr oft über mehr als nur eine Handlungsmöglichkeit verfügen. Im vorliegenden Fall gibt es mehrere Essens-Bestell-Möglichkeiten unter Corona-Bedingungen: neben dem ‚Griechen um die Ecke‘ kann Gerd auch zur ‚Pizzeria über die Straße‘ gehen. Dies ist ein bisschen weiter und bietet etwas Anderes zum Essen (Steinofen-Pizza).

Verzweigungen sind im oksimo Paradigma ausdrückbar durch das zur Verfügung stellen von mehr als einer Veränderungsregel. Ist die Wahrscheinlichkeit im Einzelfall <=1, dann wird für jeden Wahrscheinlichkeitswert ‚ausgewürfelt‚, was geschieht. Einfach gesprochen: bei einer Wahrscheinlichkeit von π=0.6 würde bei 100 Durchläufen ungefähr +/- 60 mal diese Option gewählt werden, entsprechend bei π= 0.4 ungefähr +/- 40 mal.

Im Beispiel werden für den Akteur ‚Gerd‘ zwei Optionen angenommen: zum Essen kann er entweder zum ‚Griechen um die Ecke‘ gehen oder zur ‚Pizzeria über die Straße‘. Es wird mal angenommen, dass der Akteur eher zum Griechen um die Ecke geht (weil es ’näher‘ ist) mit π=0.6, und entsprechend zur ‚Pizzeria über die Straße‘ mit π=0.4.

Bild: Überblick über das Beispiel Teil 4 mit einer Verzweigung. Das Testprotokoll von einem Simulationslauf zum Beispiel findet sich unten in einem verlinkten PDF.

Erweiterte Dokumentation mit Simulationsformen ‚Entwicklung‘ und ‚Präsentation‘ (Ergänzung: 7.Mai 2021):

ERLÄUTERUNGEN

Verzweigungen

Im einfachen Fall gibt es eine Situation, auf die mehr als eine Regel zugreifen kann. Dann werden diese Regeln alle ausgeführt, aber in einer Abfolge, die per Zufallszahlen erstellt wurde.

Handelt es sich aber um Wahrscheinlichkeiten <= 1, die als exklusiv verstanden werden sollen (also entweder zum Griechen oder zur Pizzeria), dann muss bei der Formulierung der Regeln darauf geachtet werden, dass die möglichen Alternativen explizit ausgeschlossen werden. Lässt man dies aus, dann kann es passieren dass u.a. der Akteur ‚Gerd‘ sowohl zur Pizzeria geht wie auch zum Griechen. D.h. der Akteur wird dann ‚verdoppelt‘.

Im vorgestellten Beispiel sind die Regeln als exklusive Regeln ausgelegt. Dies führt dann dazu, dass (im Protokoll) die Option ‚zum Griechen‘ bei 100 Simulations-Zyklen 10x auftritt und die Option ‚zur Pizzeria‘ 2x. Diese Verhältnisse können sich in jeder Simulation aber ändern.

Simulation, REGELDOKUMENT und REGEL

Die Testsimulation wurde mit Hilfe eines Regeldokuments mit Namen gerdhungrig1234 durchgeführt. Es wurden 100 Zyklen vorgegeben. Man kann dann die gesamte Simulation speichern oder beliebig oft wiederholen oder als Textdatei ausgeben. Im Beispiel wurde eine Simulation gespeichert und diese wurde dann wiederholt neu gestartet. Bei jedem Testlauf ändern sich die Zufallswerte.

Das Regeldokument mit Namen gerdHungrig1234 enthält die folgenden Regeln:

  • GerdWirdHungrig1
  • BestellungGriechen1
  • HungerGestillt4
  • Nachmittag1
  • Morgen1
  • Mittag1
  • GerdWirdHungrigGrieche-0-6
  • GerdWirdHungrigPizza-0-4
  • Bestellung Pizzeria1
  • HungerGestilltPizza1
  • NachmittagPiz1
  • ZumGriechen2-0-6
  • ZurPizzeria1-0-4

Die Regeln selbst sind auf dem vorausgehenden Bild abgebildet.

Man kann Regeldokumente leicht abändern durch Löschen oder Hinzufügen von neuen Regeln.

PFAD-WECHSELWIRKUNGEN

Bei dem Erstellen von Fallbeschreibungen (Ausgangssituation, Vision, und Veränderungsregeln) ist es sehr oft der Fall, dass man mit einer einfachen Beschreibung anfängt, und man dann nach und nach immer mehr Aspekte des Falls erkennt und diese dann noch in die bisherige Beschreibung einbauen will. Im Prinzip ist jede(r) Autor*in ganz frei, wie er/sie dabei vorgehen will. Dabei ist allerdings zu beachten, dass es mit wachsenden Alternativen immer mehr parallele Pfade geben wird. In einer konkreten Simulation wird es zu jedem Zeitpunkt aber immer nur eine Situation S geben, die die aktuelle Situation S ist. Man muss also darauf achten, dass die Bedingungsteile von verschiedenen Regeln, die für verschiedene Pfade gedacht sind, sich auch hinreichend unterscheiden.