Versuch eine Markovkette zu Implementieren und zu Unit Testen

[Rolf B]

Hallo hmm,

ich glaube, ich habe seinerzeit (1988) meine große Programmieraufgabe mit einer Art Markovkette gelöst, ohne den Namen zu kennen. Wir sollten da ein möglichst hohes Türmchen aus einer gegebenen Menge von Bauklötzen zusammensetzen. Ich weiß nur, dass ich damals gekotzt habe, weil das Ding überhaupt nicht so wollte wie ich.

Im Folgenden sind jetzt sicherlich ein paar persönliche Vorlieben dabei, und vermutlich gibt es auch Leute, die mir widersprechen werden.

• Ich verwende private getter und setter nur dann, wenn sie Logik enthalten. Ansonsten greife ich direkt auf die Objekteigenschaft zu. Es gibt Leute, die das anders sehen, sie sagen: „Es könnte ja mal Logik hineinkommen“ - ja. Aber bei PRIVATEN gettern/settern ist das kein Beinbruch. Klassen sollten eh nicht zu riesig werden.

• Das Ergebnis "teurer" Operationen cache ich in lokalen Variablen. Zum Beispiel in train der Wert von getSymbolCandleMap().get(symbol).

• Du solltest einheitlich darin sein, wie Du eine Vertex repräsentierst. In der Vertex-Hashmap ist der Vertex-Key ein String. Eine Edge, die zwei Vertexe verbindet, sollte demzufolge als StochTuple<String,String> repräsentiert sein. Alles andere führt nur zu sinnlosem Hin- und Herrechnen zwischen Integer und String und bläht den Code auf.

• Eigentlich verstehe ich die train-Methode nicht. Die Kette aus Vertices und Edges, die Du da erzeugst, ist mir rätselhaft. Das mag aber auch daran liegen dass ich die Fachlichkeit nicht kenne.

• Folgenden Code der train-Methode verstehe ich aber gar nicht. (1) Warum die Size der Map und nicht die Size der Liste eines Symbols. (2) Warum wird eine Edge für eine Vertex erzeugt, die nicht in der Vertex-Liste ist?

        if (i != getSymbolCandleMap().size() - 1) {
					graph.addVertex(nextVertex);
				}
				graph.addEdge(activVertex, nextVertex);

• Dein Check-Teil von trainTest ist zu wenig. Du müsstest schon genau prüfen, welche Vertext und Edges für deine Test-Candles entstanden sind.

• Die updateToProgGraph-Methode schreit laut: „entkerne mich!“. Das sind 4 Schleifen ineinander, mutmaßlich verdient jeder Schleifenrumpf eine eigene Methode. Um nicht zu viele Parameter durchschleifen zu müssen, könnte man eine Worker-Klasse in Erwägung ziehen, die newGraph und helperGraph als Eigenschaften enthält und die einzelnen Schleifenebenen als Methoden enthält. Diese Workerklasse kannst Du dann auch schön genüsslich testen; insbesondere ob die Formeln ganz innen tun, was sie sollen.

Rolf