Hallo,
ich habe mich ja vor einer Weile damit beschäftigt, wie man sich fürs 6 aus 49 Lotto ein System bauen kann, das man spielt und garantiert 3 Richtige damit hat.
Was ich mental bis auf Weiteres aufgab.
Nun kamen mir zu dem Thema neue Gedanken, zu denen mich die Meinung der Meute interessieren würde.
Mein Gedankengang:
Es gebe eine Liste A, die alle möglichen Lottozahlen enthält, die bei einer Ziehung 6 aus 49 vorkommen.
Also wo Alles von (1,2,3,4,5,6) bis (44,45,46,47,48,49) drin ist, der Einfachheit halber auch in dieser aufsteigend sortierten Reihenfolge.
Es gebe eine Liste B, die alle möglichen 3 Tupel aus dem selben Zahlenraum enthält.
Also B enthält Alles von (1,2,3) bis (47,48,49).
Und dann noch eine Lsite C, die letztlich eine Teilmenge von A ist und ebenso entsprechende 6Tupel enthält.
Liste A und B lassen sich programmiertechnisch erstellen, Liste C ist vorgegeben und ist per se schon bei Erhalt möglichst klein (wobei klein relativ ist, wer reden immer noch von tausenden Einträgen)
Wir wollen C im Endeffekt Schritt für Shcritt immer kleiner mahcen, solange das geht, ohne die "3 gewinnt" Regel zu verletzen (was die genau bedeutet, ist unwichtig an dieser Stelle. Wir wollen jedenfalls Elemente aus C rauskicken)
Im 1. Abstraktionsschritt will ich gar nicht mehr vom Element (1,2,3,4,5,6) aus A reden, sondern nur vom 1. Element aus A.
Also die Elemente in A durchnummerieren und Listenelemente nur noch durch ihren Index ansprechen.
Gleiches mache ich für B und C.
Dementsprechend kann ich auch genausogut hingehen und sagen, statt der 6Tupel besteht die Liste aus natürlichen Zahlen.
Weil für das Folgende nicht mehr wirklich das 6Tupel an sich wichtig ist, sondern nur seine Position in der Liste.
Dann enthält A eben die 6Tupel Nummer 1 bis 13983816 (bzw. 0 bis 13983815, weil wir informatiker sind! ;-))
B enthält die 3Tupel Nummer 0 bis 18424.
Und C die 6Tupel 0 bis ... (hängt halt von der übergebenen Lsite ab, wie lang die ist).
Im Übrigen wird, da C Teilemenge von A ist, manches 6Tupel in C einen anderen Index haben als in A.
Stört uns aber nicht weiter.
Jetzt wirds etwas umständlich zu erklären (Falls es das nicht eh schon war):
Man kennt vielleicht noch aus dem Matheunterricht (oder eher Uniunterricht) den Zeitpunkt wo bijektive, surjektive und Co. Funktionen vorgestellt wurden.
Und das hübsche Diagramme wo Elementen aus einer Menge Elemente ausn eienr anderen Menge zugeordnet wurdne und man da Richtungspfeile zwischen den Elementen zeichnete.
Da meine Zeichenkünste mies sind, stelle man sich Folgendes geistig vor:
Links haben wir senkrecht untereinander alle Elemente aus A, alle 13983816 Stück.
Kann man sich durchaus einfahc als die Zahlen 1-13983816 untereinander gechrieben vorstellen.
Gleichermassen haben wir mittig senkrecht untereinander alle Zahlen aus B, also die Nummern 1-18424 untereinander.
Rechts haben wir senkrecht untereinander alle Zahlen als C.
Nun gehen wir hin und zeichnen Pfeile von den Elemente links zu denen in der Mitte wie folgt:
Wir verbind jedes Element aus A mit den Elementen aus B, die darin enthalten sind.
Zur Erinnerung:
A enthält ursprünglich 6Tupel und B 3Tupel.
Für jedes 6Tupel aus A gehen also Pfeile weg zu den 20 verschiedenen 3Tupeln aus B, die darin enthalten sind.
heißt von jedem Element links gehen 20 Pfeilen zu unterschiedlichen Elementen in der Mitte.
Auf gleiche weise zeichne n wir zwischen Mitte und rechts Verbindungen ein, wo ein 3Tupel aus B in einem 6Tupel aus C enthalten ist.
Faktisch geht dann auch von jedem Objekt rechts 20 Pfeile zu Elementen in der Mitte.
So viel zur Anschauung.
Nun zum Teil, der auch nur im Entferntesten mit Programmieren zu tun hat:
Jedes Element in der Mitte merkt sich auf irgendeine Weise, keine Ahnung wie bisher,
wie viele nach rechts gehende Pfeile es hat.
gehen von einem mittigen Element 5 Pfeile nach rechts, merkt es sich die zahl 5.
Weiterhin, das wäre zumindest sehr nice, sollte ein Element links in der Lage sein, von jedem mittigen Element zu sehen , welche Nummer sich dieses merkt.
Da jedes linke Element mit 20 mittigen lementen verbunde ist (was sich auch nie ändern wird), geht das linke Element hin, nimmt die von den 20 Mittenelementen gespeicherten Nummern und addert diese, die es sich in einem eigenen Counter merkt.
Faktisch sind dies alle (verschiedenen) Wege, wie man von dem Element links zu einem Element rechts kommen kann.
Praktisch wäre es, falls sich bei einem mittigen Element dessen Zähler verändert, dass alle linkenden Elemente, deren Zähler davon abhängen, sich auch synchron mit verändern würden.
Abseits davon soll wiederum jedes Element rechts im hinterkopf behalten könnnen, mit welchen Elementen in der Mitte es verbunden ist.
Nun zum programmiertechnischen:
Eingangs werden selbstredend die 3 Lsiten gebaut und deren Indizierung vorgenommen (ich denke da an Excel oder, fotgeschrittener, 2-3 mysql Tabellen wo einfahc in der linken Spalte das Listenelement (das konkrete 6 oder 3tupel) steht und rechts dessen index.
Und halt irgendwie alle nötigen Infos für die Zähler und so merken.
Die mittige Liste aus 18424 Zählern würde ich ganz primitiv als Array der Länge 18424 initialisieren, alle Werte eignangs auf 0.
Und dann für jede Element aus C hingehen und bei dem Element , mit dem es verbunden ist, den Zähler um 1 erhöhen.
Will sagen: die 1. zahl aus C hat sich ja gemerkt, mit welchen 20 Elementen aus B sie verbunden ist.
Dann werden bei diesen 20 Elementen aus B die zugehörigen Zähler jeweils um 1 erhöht.
Womit wir auch zur gegenrichtugn kommen:
Wird eine Zahl aus C entfernt, dann werden die 20 damit verbundenen Zähler aus B jeweils um 1 erniedrigt.
Nun zur "Strategie" wie man hingehen könnte und die rechte Liste verkleinern könnte ohne (hoffentlich) die Gewinnbedingung zu verletzen:
Man geht ganz nach altem Stil der Reihe nahc die Elemente aus C durch und teste für jedes Element:
Sagen wir, wir streichen das 1. Element aus C.
Dann gehen dadurch bei 20 Elementen aus B der Zähler um 1 nach unten.
Weil ja verbunden, gehen dadurch auch bei vielen Elementen aus A deren zähler um 1 nach unten.
Wir gucken nun also:
Wenn wir hingehen und entfernen das 1. element aus C, sind dann noch die zähler aller Elemente aus A größer 0?
Falls ja, war das 1. Element aus C überflüssig und kann entfernt werden.
Falls nein, ist es notwendig und wir versuchen uns mit dem 2. Element aus C.
so machen wir, falls erforderlich, die C Liste durch und finden entweder etwas, was entfernt werden kann.
Oder wir gelangen ans Listenende und habend aher shcon eine optimale Liste.
Just for Fun gehen wir hin und speichern uns in der Hinterhand ab, ausgehend von der eingangs erhaltenen Liste C, in welcher Reihenfolge wir welche Elemente aus C entfernt haben.
Das hat den Hintergrund, dass es ja womöglich mehrere "optimale Listen" gibt wovon Manche kürzer sind als Andere. Und kürzer und trotzdem optimal ist unser Ziel.
So könne wir ggbfls. später verschiedene Vorgehensweisen durchprobieren wenn mehrere Elemente in einer Runde zur Löschung zulässig wären, welche Endliste wir am Ende diesen oder jenen Pfades erhalten
Langer Rede kurzer Sinn:
Einen solchen Algorithmu würde ich gerne umsetzen.
Wobei mir, je länger ich drüer schreibe, umso mehr klar wird dass vermutlichsich das Ganze recht easy in Excel darstellen liesse und ein passendes Java programm einfach nur die Exceltabelle immer wieder verändert.
ich habe mich ja vor einer Weile damit beschäftigt, wie man sich fürs 6 aus 49 Lotto ein System bauen kann, das man spielt und garantiert 3 Richtige damit hat.
Was ich mental bis auf Weiteres aufgab.
Nun kamen mir zu dem Thema neue Gedanken, zu denen mich die Meinung der Meute interessieren würde.
Mein Gedankengang:
Es gebe eine Liste A, die alle möglichen Lottozahlen enthält, die bei einer Ziehung 6 aus 49 vorkommen.
Also wo Alles von (1,2,3,4,5,6) bis (44,45,46,47,48,49) drin ist, der Einfachheit halber auch in dieser aufsteigend sortierten Reihenfolge.
Es gebe eine Liste B, die alle möglichen 3 Tupel aus dem selben Zahlenraum enthält.
Also B enthält Alles von (1,2,3) bis (47,48,49).
Und dann noch eine Lsite C, die letztlich eine Teilmenge von A ist und ebenso entsprechende 6Tupel enthält.
Liste A und B lassen sich programmiertechnisch erstellen, Liste C ist vorgegeben und ist per se schon bei Erhalt möglichst klein (wobei klein relativ ist, wer reden immer noch von tausenden Einträgen)
Wir wollen C im Endeffekt Schritt für Shcritt immer kleiner mahcen, solange das geht, ohne die "3 gewinnt" Regel zu verletzen (was die genau bedeutet, ist unwichtig an dieser Stelle. Wir wollen jedenfalls Elemente aus C rauskicken)
Im 1. Abstraktionsschritt will ich gar nicht mehr vom Element (1,2,3,4,5,6) aus A reden, sondern nur vom 1. Element aus A.
Also die Elemente in A durchnummerieren und Listenelemente nur noch durch ihren Index ansprechen.
Gleiches mache ich für B und C.
Dementsprechend kann ich auch genausogut hingehen und sagen, statt der 6Tupel besteht die Liste aus natürlichen Zahlen.
Weil für das Folgende nicht mehr wirklich das 6Tupel an sich wichtig ist, sondern nur seine Position in der Liste.
Dann enthält A eben die 6Tupel Nummer 1 bis 13983816 (bzw. 0 bis 13983815, weil wir informatiker sind! ;-))
B enthält die 3Tupel Nummer 0 bis 18424.
Und C die 6Tupel 0 bis ... (hängt halt von der übergebenen Lsite ab, wie lang die ist).
Im Übrigen wird, da C Teilemenge von A ist, manches 6Tupel in C einen anderen Index haben als in A.
Stört uns aber nicht weiter.
Jetzt wirds etwas umständlich zu erklären (Falls es das nicht eh schon war):
Man kennt vielleicht noch aus dem Matheunterricht (oder eher Uniunterricht) den Zeitpunkt wo bijektive, surjektive und Co. Funktionen vorgestellt wurden.
Und das hübsche Diagramme wo Elementen aus einer Menge Elemente ausn eienr anderen Menge zugeordnet wurdne und man da Richtungspfeile zwischen den Elementen zeichnete.
Da meine Zeichenkünste mies sind, stelle man sich Folgendes geistig vor:
Links haben wir senkrecht untereinander alle Elemente aus A, alle 13983816 Stück.
Kann man sich durchaus einfahc als die Zahlen 1-13983816 untereinander gechrieben vorstellen.
Gleichermassen haben wir mittig senkrecht untereinander alle Zahlen aus B, also die Nummern 1-18424 untereinander.
Rechts haben wir senkrecht untereinander alle Zahlen als C.
Nun gehen wir hin und zeichnen Pfeile von den Elemente links zu denen in der Mitte wie folgt:
Wir verbind jedes Element aus A mit den Elementen aus B, die darin enthalten sind.
Zur Erinnerung:
A enthält ursprünglich 6Tupel und B 3Tupel.
Für jedes 6Tupel aus A gehen also Pfeile weg zu den 20 verschiedenen 3Tupeln aus B, die darin enthalten sind.
heißt von jedem Element links gehen 20 Pfeilen zu unterschiedlichen Elementen in der Mitte.
Auf gleiche weise zeichne n wir zwischen Mitte und rechts Verbindungen ein, wo ein 3Tupel aus B in einem 6Tupel aus C enthalten ist.
Faktisch geht dann auch von jedem Objekt rechts 20 Pfeile zu Elementen in der Mitte.
So viel zur Anschauung.
Nun zum Teil, der auch nur im Entferntesten mit Programmieren zu tun hat:
Jedes Element in der Mitte merkt sich auf irgendeine Weise, keine Ahnung wie bisher,
wie viele nach rechts gehende Pfeile es hat.
gehen von einem mittigen Element 5 Pfeile nach rechts, merkt es sich die zahl 5.
Weiterhin, das wäre zumindest sehr nice, sollte ein Element links in der Lage sein, von jedem mittigen Element zu sehen , welche Nummer sich dieses merkt.
Da jedes linke Element mit 20 mittigen lementen verbunde ist (was sich auch nie ändern wird), geht das linke Element hin, nimmt die von den 20 Mittenelementen gespeicherten Nummern und addert diese, die es sich in einem eigenen Counter merkt.
Faktisch sind dies alle (verschiedenen) Wege, wie man von dem Element links zu einem Element rechts kommen kann.
Praktisch wäre es, falls sich bei einem mittigen Element dessen Zähler verändert, dass alle linkenden Elemente, deren Zähler davon abhängen, sich auch synchron mit verändern würden.
Abseits davon soll wiederum jedes Element rechts im hinterkopf behalten könnnen, mit welchen Elementen in der Mitte es verbunden ist.
Nun zum programmiertechnischen:
Eingangs werden selbstredend die 3 Lsiten gebaut und deren Indizierung vorgenommen (ich denke da an Excel oder, fotgeschrittener, 2-3 mysql Tabellen wo einfahc in der linken Spalte das Listenelement (das konkrete 6 oder 3tupel) steht und rechts dessen index.
Und halt irgendwie alle nötigen Infos für die Zähler und so merken.
Die mittige Liste aus 18424 Zählern würde ich ganz primitiv als Array der Länge 18424 initialisieren, alle Werte eignangs auf 0.
Und dann für jede Element aus C hingehen und bei dem Element , mit dem es verbunden ist, den Zähler um 1 erhöhen.
Will sagen: die 1. zahl aus C hat sich ja gemerkt, mit welchen 20 Elementen aus B sie verbunden ist.
Dann werden bei diesen 20 Elementen aus B die zugehörigen Zähler jeweils um 1 erhöht.
Womit wir auch zur gegenrichtugn kommen:
Wird eine Zahl aus C entfernt, dann werden die 20 damit verbundenen Zähler aus B jeweils um 1 erniedrigt.
Nun zur "Strategie" wie man hingehen könnte und die rechte Liste verkleinern könnte ohne (hoffentlich) die Gewinnbedingung zu verletzen:
Man geht ganz nach altem Stil der Reihe nahc die Elemente aus C durch und teste für jedes Element:
Sagen wir, wir streichen das 1. Element aus C.
Dann gehen dadurch bei 20 Elementen aus B der Zähler um 1 nach unten.
Weil ja verbunden, gehen dadurch auch bei vielen Elementen aus A deren zähler um 1 nach unten.
Wir gucken nun also:
Wenn wir hingehen und entfernen das 1. element aus C, sind dann noch die zähler aller Elemente aus A größer 0?
Falls ja, war das 1. Element aus C überflüssig und kann entfernt werden.
Falls nein, ist es notwendig und wir versuchen uns mit dem 2. Element aus C.
so machen wir, falls erforderlich, die C Liste durch und finden entweder etwas, was entfernt werden kann.
Oder wir gelangen ans Listenende und habend aher shcon eine optimale Liste.
Just for Fun gehen wir hin und speichern uns in der Hinterhand ab, ausgehend von der eingangs erhaltenen Liste C, in welcher Reihenfolge wir welche Elemente aus C entfernt haben.
Das hat den Hintergrund, dass es ja womöglich mehrere "optimale Listen" gibt wovon Manche kürzer sind als Andere. Und kürzer und trotzdem optimal ist unser Ziel.
So könne wir ggbfls. später verschiedene Vorgehensweisen durchprobieren wenn mehrere Elemente in einer Runde zur Löschung zulässig wären, welche Endliste wir am Ende diesen oder jenen Pfades erhalten
Langer Rede kurzer Sinn:
Einen solchen Algorithmu würde ich gerne umsetzen.
Wobei mir, je länger ich drüer schreibe, umso mehr klar wird dass vermutlichsich das Ganze recht easy in Excel darstellen liesse und ein passendes Java programm einfach nur die Exceltabelle immer wieder verändert.
