<commit_before>\chapter{Überblick über die Engine}

\section{Das Rendersystem}

Das Rendersystem basiert auf dem Konzept eines Mealy Automatens \cite{Mealy1955}. Ein Mealy Automat ist Transduktor oder \ac{FST}, ein spezieller endlicher Automat, der nicht nur seine Eingabesprache vom Eingabeband akzeptiert sondern auch eine Ausgabe auf einem Ausgabeband erzeugt. Ein Transduktor übersetzt die Eingabesprache in eine Ausgabesprache. Bei dem Mealy Automaten als spezielle Form definiert sich die Ausgabe über den momentanen Zustand und der Eingabe auf diesem Zustand. Formal lässt sich ein Mealy Automat $\mathbfcal{M}$ als 6-Tupel wie folgt definieren:

\[
\mathbfcal{M} = \left( Q, \Sigma, \Omega, \delta, \lambda, q_0 \right)
\]
\begin{align*}
	\text{mit}\\
	Q &: \text{Endliche Menge von Zuständen} \\
	\Sigma  &:\text{Endliches Eingabealphabet} \\
	\Omega  &:\text{Endliches Ausgabealphabet} \\
	\delta  &:\text{Zustandsübergangsfunktion}\ Q \times \Sigma \rightarrow Q \\
	\lambda &:\text{Ausgabefunktion}\ Q \times \Sigma \rightarrow \Omega \\
	q_0 &: \text{Startzustand}
\end{align*}

Die Definition ließe sich noch um die Menge der finalen Endzustände $F \subseteq Q$ erweitern. In unserem Konzept verzichten wir auf definierte Endzustände, da wir prinzipiell jede Eingabe akzeptieren. Nicht akzpetierbare Eingaben stellen wir als externe Ausnahmefälle (Exceptions) dar. Ein vereinfachtes Beispiel für eine nicht akzeptierbare Eingabe ist die Eingabe $\bot$, nach der unser gesamtes System in einen undefinierten Zustand $\bot$ wechselt.

Die Praktische Implementierung:
\begin{lstlisting}[language=Haskell]
newtype Mealy a b = Mealy { runMealy :: a -> (b,Maely a b) }
\end{lstlisting}
https://hackage.haskell.org/package/machines-0.4.1/docs/Data-Machine-Mealy.html

Das Konzept verfolgt das Ziel, dass jeder Abschnitt (Pass) in der Renderpipeline ein von der Außenwelt isolierten lokalen Zustand besitzt. Der Folgezustand definiert sich über zwei Größen, entsprechend dem Mealy Konzept, aus dem momentanten Ist-Zustand und dem Input. Jeder Pass kann somit im lokalen Zustand von Zählvariablen bis hin zu Resourcen verwalten. Eingehende und ausgehende Resourcen werden klar über die Eingae und Ausgabeschnittstellen eines Passes definiert. Dies hebt sich von objektorientierten Konzepten in der Art ab, dass der Zustand des Typens nicht über diverse Methoden verändert wird (z.B. häufig über setter/getter), sondern ein Pass für eine Ausfühung alle benötigten Daten als Input erhält. Zu dieser Eingabe wird eindeutig eine Ausgabe erzeugt.

Monadische Mealy
\begin{lstlisting}[language=Haskell]
newtype RenderSystem m i o = RenderSystem { runRenderSystem :: i -> m (o, RenderSystem m i o) }
\end{lstlisting}

Die Mealy wurde hier um einen monadischen erweitert (Transformation). Die Notwendigkeit für eine monadischen Mealy besteht darin, dass wir in unserem Pass IO Operationen ausführen müssen, wie z.B. Ausführung von OpenGL Befehlen. Zusätzlich erhöht es die Flexibilität, so können wir auch globale Umgebungen z.B. über die Reader-Monade definieren (Anwendung DeferredSettings). Theoretisch währes es auch über monadische Komponente der Mealy möglich den lokalen Zustand, z.B. über IORef, zu exponieren. Dies liegt aber entsprechend in der Verantwortung der Implementierung.<commit_msg>next text draft for mealy<commit_after>\chapter{Überblick über die Engine}

\section{Das Rendersystem}

\warn{Wir beschreiben den sinn und zweck des Renderystems hier. Das Rendersystem ist der Kern der Renderkomponente der Engine. Die Aufgabe des Rendersystems ist eine Eingabe zu einem Bild darzustellen... Im Konkreten Fall erhält das RenderSystem eine Szenenbeschreibung als Eingabe und führt auf Basis dieser alle definierten Schritte um die Szene in der gewünschten Darstellung als Bild zu synthetisieren.}

\subsection{Mealy als Formale Basis}

Das Rendersystem basiert auf dem Konzept eines Mealy Automatens \cite{Mealy1955}. Ein Mealy Automat ist Transduktor oder \ac{FST}, ein spezieller endlicher Automat, der nicht nur seine Eingabesprache vom Eingabeband akzeptiert sondern auch eine Ausgabe auf einem Ausgabeband erzeugt. Ein Transduktor übersetzt die Eingabesprache in eine Ausgabesprache. Bei dem Mealy Automaten als spezielle Form definiert sich die Ausgabe über den momentanen Zustand und der Eingabe auf diesem Zustand. Formal lässt sich ein Mealy Automat $\mathbfcal{M}$ als 6-Tupel wie folgt definieren:

\[
\mathbfcal{M} = \left( Q, \Sigma, \Omega, \delta, \lambda, q_0 \right)
\]
\begin{align*}
	\text{mit}\\
	Q &: \text{Endliche Menge von Zuständen} \\
	\Sigma  &:\text{Endliches Eingabealphabet} \\
	\Omega  &:\text{Endliches Ausgabealphabet} \\
	\delta  &:\text{Zustandsübergangsfunktion}\ Q \times \Sigma \rightarrow Q \\
	\lambda &:\text{Ausgabefunktion}\ Q \times \Sigma \rightarrow \Omega \\
	q_0 &: \text{Startzustand}
\end{align*}

Die Definition ließe sich noch um die Menge der finalen Endzustände $F \subseteq Q$ hin zu einem 7-Tupel erweitern. In unserem Konzept verzichten wir auf definierte Endzustände, da wir prinzipiell jede Eingabe akzeptieren. Nicht akzpetierbare Eingaben stellen wir als externe Ausnahmefälle (Exceptions) dar. Ein vereinfachtes Beispiel für eine nicht akzeptierbare Eingabe ist die Eingabe $\bot$, nach der unser gesamtes System in einen undefinierten Zustand $\bot$ wechselt.

\subsubsection{Abstrakte Definition in Haskell}

Ein Mealy Automat lässt sich in Haskell abstrakt wie in \fref{lst:haskell-mealy} definieren. {\tt a} beschreibt die Eingabe als Äquivalent zum Eingabealphabet $\Sigma$ der formalen Definition und analog beschreibt {\tt b} die Ausgabe als Äquivalent zum Ausgabealphabet $\Omega$. Die Zustandsübergangsfunktion $\delta$ und die Ausgabefunktion $\lambda$ ergibt sich aus der jeweils konkreten Implementierung des Mealy. Die Menge der Zustände $Q$ wird jeweils von der konkreten Mealy gekapselt wie in \fref{lst:state-mealy-beispiel} anhand eines Beispiels veranschaulicht. Aber es lässt sich bereits feststellen, dass die gewählte Form des Mealy Automatens weit mehr als nur ein endlicher Automat ist, da sowohl die Menge der Zustände als auch das Ein- und Ausgabealphabet auch überabzählbar sein kann.

\begin{lstlisting}[language=Haskell,label={lst:haskell-mealy},caption={Definition Mealy in Haskell\protect\footnotemark},float]
newtype Mealy a b = Mealy { runMealy :: a -> (b, Maely a b) }
\end{lstlisting}
\footnotetext{https://hackage.haskell.org/package/machines-0.4.1/docs/Data-Machine-Mealy.html}

Veranschaulichung der funktionsweise eines konkreten Mealy Automaten mit einem Lokalen Zustand.

Diese Definition einer Meleay gehört einiger nützlicher Klassen an, die wir aber hier überspringen da wir in \fref{sec:konkret-rendersystem} für unsere erweiterte monadische Definition eigene Implementierungen entwickeln werden.

\subsection{Konkrete Definition des Rendersystems}
\label{sec:konkret-rendersystem}

Das Konzept verfolgt das Ziel, dass jeder Abschnitt (Pass) in der Renderpipeline ein von der Außenwelt isolierten lokalen Zustand besitzt. Der Folgezustand definiert sich über zwei Größen, entsprechend dem Mealy Konzept, aus dem momentanten Ist-Zustand und dem Input. Jeder Pass kann somit im lokalen Zustand von Zählvariablen bis hin zu Resourcen verwalten. Eingehende und ausgehende Resourcen werden klar über die Eingae und Ausgabeschnittstellen eines Passes definiert. Dies hebt sich von objektorientierten Konzepten in der Art ab, dass der Zustand des Typens nicht über diverse Methoden verändert wird (z.B. häufig über setter/getter), sondern ein Pass für eine Ausfühung alle benötigten Daten als Input erhält. Zu dieser Eingabe wird eindeutig eine Ausgabe erzeugt.

Monadische Mealy
\begin{lstlisting}[language=Haskell]
newtype RenderSystem m i o = RenderSystem { runRenderSystem :: i -> m (o, RenderSystem m i o) }
\end{lstlisting}

Die Mealy wurde hier um einen monadischen erweitert (Transformation). Die Notwendigkeit für eine monadischen Mealy besteht darin, dass wir in unserem Pass IO Operationen ausführen müssen, wie z.B. Ausführung von OpenGL Befehlen. Zusätzlich erhöht es die Flexibilität, so können wir auch globale Umgebungen z.B. über die Reader-Monade definieren (Anwendung DeferredSettings). Theoretisch währes es auch über monadische Komponente der Mealy möglich den lokalen Zustand, z.B. über IORef, zu exponieren. Dies liegt aber entsprechend in der Verantwortung der Implementierung.

{'fraction_non_alphanumeric': 0.06394105062990255, 'fraction_numerical': 0.0024958402662229617, 'mean_word_length': 5.160322108345534, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1534020', 'n_tokens_mistral': 2773, 'n_tokens_neox': 2836, 'n_words': 1040}