- Start
- |
- Gemeinschaft
- |
- Modelle
- |
- Infos
- |
- Markt
- |
- Hilfe+Kontakt
- |
- |
Hallo,
Ingo hat mich vor ein paar Tagen auf das Lego Puzzle aufmerksam gemacht. Wir kennen uns schon lange, seit ich mich vor vielen Jahren mit dem Eternity-Puzzle beschäftigt habe https://de.wikipedia.org/wiki/Eternity-Puzzle. Davon gibt es eine neue Variante, Eternity 2, und die hat sehr viel Ähnlichkeit mit dem 4-Farben-Lego Problem. Aus diesem Grund empfehle ich http://cs.brown.edu/peopl...Papers/v3/eternity.pdf , viele Ideen daraus lassen sich auf das Lego-Problem übertragen.
Die Reihe-für-Reihe Strategie ist für Eternity 2 sehr gut. Beim Lego-Problem gibt es im Gegensatz zu Eternity 2 keinen definierten "Rand", füllen wir die z.B. die erste Reihe, haben wir fast nur 1-Seiten-Constraints. Eine Strategie, die immer größere Quadrate beginnend in einer Ecke konstruiert hat schneller 2-Seiten-Constraints und müsste theoretisch besser sein.
Das lässt sich mit dem 2-Farben-Lego Problem leicht beweisen, statt ca. 80000 haben wir nur noch ca. 70000 Versuche. Der Vorteil für das 4-Farben Lego sollte größer sein.
Aus Eternity 1 haben wir gelernt, das es sich lohnt, am Anfang die Suche einzuschränken, wenn dafür am Schluss "besser zusammenpassende" Teile übrigbleiben. Nehmen wir z.B. das 9x9er 3-Farben Problem:
Wenn wir am Anfang nur die 16 Teile mit den ersten beiden Farben verbauen (Eine Lösung des 4x4er 2-Farben Problems) bleiben nur Teile übrig, die alle die dritte Farbe haben und theoretisch mit höherer Wahrscheinlichkeit zusammenpassen. Das ganze lässt sich analog auf das 4-Farben Problem mit vordefiniertem 9x9er übertragen.
Auch die Frage, ob es sich lohnt in Assembler zu programmieren, oder ob eine Programmiersprache wie z.B. Java reicht, war vor 16 Jahren in Bezug auf Eternity 1 schon aktuell. Nur 3 Personen konnten das Puzzle lösen, einer davon (Günter Stertenbrink) benutzte Assembler. Allerdings war dann später ein Java Programm in der Lage, schneller weitere Lösungen zu berechnen.
Für das Lego 2-Color Problem haben wir 2ms für 80000 Versuche für Assembler, mein Java-Programm braucht 2.5 ms. Da man in Java leichter neue Ideen (wie die oben beschriebenen) ausprobieren kann, scheint auch hier der Assembler-Vorteil überschaubar, zumal wir es heute in der Regel mit Multi-Thread Prozessoren zu tun haben. Die Parallelisierung der Suche lässt sich in Assembler nur schwer realisieren.
Mir gefällt das Lego-Problem besonders, weil es neben dem "schwierigen" 4-Farben Problem die lösbare 3-Farben Variante gibt. Die kann man benutzen, um Ideen in Bezug auf Verbesserungen des Suchverfahrens zu testen.
Für das 4-Farben Problem habe ich bis jetzt übrigens auch nur mehrere 254er Teillösungen gefunden. Durch betrachten der Suchergebnisse in Tiefe 79-81 des 3-Farben-Problems versuche ich jetzt, Ideen für eine Verbesserung zu finden. 253 Teile war übrigens auch mein bestes Ergebnis mit der einfachen Reihe-für-Reihe Strategie.
Grüsse Dietmar
