Lottozahlen Generator
(später auch: Designpatterns für komplexe numerische Systeme)

Technologien: C#, WCF, XML, PHP, (Design Patterns)

Motivation

Start und Antrieb des Projekts war es den Lotto 6er, auf Grund der Einhaltung des statistischen Verlaufes der Theorie zur Praxis, zu berechnen. Es soll dabei keine Aussage darüber getroffen werden, welche Zahlen in der nächsten Spielrunde enthalten sein werden, sondern welche Filter, auf Grund von selten wiederkehrenden, bzw. kürzlich zustande gekommenen Systemen, angewandt können werden. -> Inspiration: Stochastik. Die Anwendung dient also nicht zur Aufstellung einer Menge von Tipps, wovon sich einer in der nächsten Runde als den 6er erweisen sollte, sondern eines Ausschlussverfahrens, das auf Grund des statistischen Verlaufs, Tipps als „unwahrscheinlich“ wertet. Der Kehrwert dieser soll dann als „wahrscheinlicher“ hervorgehen.

Beschreibung

Komplexe Filter wurden programmiert, um jeden in der Menge der möglichen Spieltipps einen Booleschen Wert zuzuweisen. Die Algorithmen für jene Reduzierungsstufen manifestieren sich in down-gecasteten Klassen des Core-Objects. Da unter C# die Vererbung von Form-Klassen zur Verwendung selber Methoden nicht möglich ist, ohne dabei den Designer zu zerstören, wird in der Klassendeklaration das Interface mitgegeben. Somit ist es möglich ein Window-Klassen-Array mit jeweiligem Designer zu erstellen und dennoch einheitlichen Methoden zu ermöglichen. Diese sind notwendig, um mit dem Controller, dessen Aufgabe die Gesamtauswertung ist, kommunizieren zu können.

Da der Initialisierungsaufwand aller Stufen sich als den aufwändigsten Part etablierte, in Bezug auf Ladevorgang und Speicherreservierung, wurden Core- und Designklassen voneinander getrennt. Die Corejobs wurden in eine WCF-Service-Library eingebunden und über einen eigens erstellten DynDNS gehostet. Der Client holt sich bei Nichterreichung die neue private IP Adresse des privaten Servers von einer Webseite ab. Somit wurde das Programm auch für jene zugänglich, dessen Rechner nicht den eigentlichen Anforderungen entsprach.

Der Benutzer lädt das Programm, wobei zum Start alle Vorberechnungen, bzw. die Optionen zur dynamischen Berechnung geschaffen werden, um bei dem Vorgang, 8 Mio. Tipps über einen benutzerdefinierten Filter zu legen, kaum Wartezeiten zu erhalten. Im folgenden Screenshot hat der Benutzer die Möglichkeit die Anzahl von Primzahlen in einem Spieltipp für die nächste Runde zu bestimmen.

Bei der Anwendung blättert sich der Benutzer durch die einzelnen Filterstufen, die mit den statistischen Verläufen der Spielrunden und gesamten Vorkommnissen gefüllt sind und verändert durch Klicken den Bandpass der allzulässigen Menge auf eine Geringere. Alle Stufen sind durch eine disjunktive Normalform (DNF) verknüpft, die bei der Auswertung die überbleibende Menge aller Reduzierungen angibt.

Im folgenden Screenshot bekommt der Benutzer eine Einsicht darüber, wie lange jene Zahlen nicht mehr vorkamen. Nach einer neuen Spielrunde werden die Counters der jeweiligen Zahlen wieder auf 0 gesetzt.

Der Benutzer kann eine Menge von „wahrscheinlichen“ Zahlen zusammenfassen und anschließend als Formel interpretieren. Hierbei bietet sich die Strategie der am längsten nicht mehr vorgekommenen Zahlen an.

Der Benutzer beschreibt sein Vorhaben, indem er die aufgestellten Zahlen nacheinander angibt und hinterher die Reduzierungsoption festlegt. Die Zahlen nach dem Operationszeichen stellen die Grenzwerte für die Anzahl jener Spielzahlen dar. Anschließend wird ein „r“ für reduce oder ein „c“ für conserve angestellt.

In diesem Fall hätte der Benutzer eingetragen, dass alle Tipps aus den 8 Mio. Möglichkeiten entfernt werden sollen, wenn sie nicht null oder eine Zahl aus der angegebenen Menge beinhalten würden. Der Interpreter sorgt zusätzlich für die einheitliche Formulierung und optimiert bei komplexeren Eingaben jene benutzerspezifische Formel, um sie auf Redundanz und Ausführbarkeit zu überprüfen.

Ein Filter ist wie beschrieben, eine Betrachtung der Eigenschaften eines Tipps. Einfache Stufen beschränken sich auf Wiederkehren von Tipps, Anzahl von Primzahlen, Abstände und Größe der Felder von Zahlengruppen. Komplexere beschäftigen sich mit dynamischen Listen und statistischen Häufigkeiten von Zahlengruppen zu errechnen.

Unschärfe

Je mehr Entscheidungen über das künftige Verhalten der Ziehung getroffen werden, umso höher fällt die Fehlerquote aus. Viele Entscheidungen lassen sich auf Grund der Statistik als einfach darstellen. Um jedoch zu einer effektiven, geringen Menge zu gelangen, müssen immer mehr riskantere Reduzierungen getroffen werden, die jedoch dem statistischen Verhalten nacheifern. Dennoch verläuft es in der Praxis so, dass niemals das perfekte Verhalten vorkommt. Dieser Part ist nun ebenso reduzierbar, wie die äußerst unwahrscheinliche Menge.

Ich kann zwar nicht sagen wo die Fehler exakt geschehen, jedoch die  Anzahl dieser eingrenzen!

Nach einer fertigen Reduzierung äußere ich eine Fehlerquote. Halte ich mich innerhalb dieser auf, so werden die Gewinnzahlen korrekturgerechnet.

Hilfsmittel und Tools

Ein HTTP Request führt das Update der Ziehungen für jedes beliebige Land durch und schreibt den XML-Content in eine Textdatei, die vom Programm ausgelesen wird.

Ein Formular zur prozentuellen Auslastung der einzelnen Filterstufen soll während der Anwendung Aufschluss darüber geben, wie stark jede einzelne Stufe verwendet wird und ebenso die Überschneidungen in der Gesamtmenge angeben.

Ein Druckertreiber verhalf zum automatisierten Ausfüllen der Spielscheine für die reduzierte Menge.

Strategische Eliminierung

Die Reduzierung auf die „wahrscheinliche“ Menge pendelte sich pro Spiellauf trotz komplexer Filter auf einen zu hohen Betrag ein, sodass eine neue Erkenntnis umgesetzt werden mussten.

Jeder Tipp ist auf Grund der Zahlenpermutationen anderen Tipps aus der Gesamtmenge ähnlich. Das bedeutet, wenn nur ein Tipp gespielt werden soll, gäbe es bei der Ziehung von 6 aus 45, 234 Möglichkeiten den unteren Gewinn (5er) zu ergattern. Die Idee basiert auf der Kompromissbereitschaft, den Einsatz zu minimieren, resultierend daraus, auch weniger zu gewinnen.

Es stellte sich heraus, dass trotz der reduzierten Menge noch starke Überschneidungen existierten. Das heißt, dass ein ausgewählter Tipp in einem starken Ausmaß sein Umfeld abdeckt. Es sollte eine neue geringere Menge resultieren, die auf Grund der Überschneidungen ersten Grades hervor gingen. Jedoch wurde rasch festgestellt, dass die optimale Menge nur in einer exponentiellen Laufzeit zu berechnen möglich war und sich somit um ein np (nichtdeterministisches Polynomialzeit) schweres Problem handelte. Für eine Anwendung dieser Größe hätte sich die Berechnung pro Spielrunde auf mehrere Jahre verlaufen.

Dessen Lösungsweg brachte ein neues universell anwendbares Verfahren hervor, die RIQ