Speedcube.de Forum

Normale Version: Software für CFOP-Lösungsweg
Sie sehen gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,

ich nutze seit ca. 6 Monaten CFOP - bzw. vermutlich etwas ähnliches, denn ich brauche viel zu viele Moves. Laut einem Vergleich soll CFOP mit 55-60Moves etwas 10 Moves mehr wie Roux oder ZZ brauchen.
Zugegeben, ich beherrsche noch kein komplettes Full-OLL. Aber selbst die Fälle, wo ich kein 2-Look benötige, habe ich viel zu viele Turns. (und HTMs schon als 1 Turn gerechnet).

Jetzt suche ich Muster-Lösungen - am liebsten direkt eine Software, die mir aus einem Scramble den kurzen CFOP-Lösungsweg in üblicher Notation aufzeigt (natürlich Fälle ohne zufällige OLL/PLL-Skips, bzw. ZBLL oder ähnliche Spezialfälle oder advanced Zusatz-Algs). Kennt da vielleicht jemand etwas?
Die meisten Youtube-Solves sind einfach zu schnell, um sie selbst mit kleinster Wiedergabegeschwindikeit voll nachvollziehen zu können. Und solche, welche extra langsam raffinierte Lösungsmethoden zeigen von 5sek Solves, sind meist jene, welche auf viel Glück beruhen (eben zufällig OLL- oder PLL-Skip), bzw. Nutzung entsprechender Zusatz-Algs.


Danke im Voraus,
Dominik
So eine Software existiert meines Wissens nach nicht, weil das Ergebnis eigentlich ziemlich "einfach" zu reproduzieren wäre. Zwei Tipps an der Stelle:
1. Nicht die F2L Paare zuerst machen, die du zuerst siehst, sondern die, die einfach zu lösen sind.
2. Bei Gelegenheit mal die F2L Algorithmen Sammlung anschauen, ob man vielleicht irgendwo noch was effizienteres machen kann, als man sich selbst erdacht hat.

Die Software würde auch nur in jedem Schritt das einfachste F2L suchen und den Algorithmus ausführen, das wäre nicht wirklich eine Implementation wert. Wenn du willst kannst du aber gerne 2-3 Scramble hier reinschicken und ich schick dir meine Lösung dazu Smile
Danke für die Tipps und das Angebot.

Ich lasse trotzdem mal die Suchanfrage offen. Einiges an (alter) Software habe ich schon getestet. Ich plane demnächst auch eine eigene Software für ein Hobbyprojekt zu schreiben. Muss da aber noch einiges planen/klären - insbesondere wie man den 3x3 Cube am besten mathematisch/programmiertechnisch handled.
(07.09.2020, 20:38)AstroCuber schrieb: [ -> ]Danke für die Tipps und das Angebot.

Ich lasse trotzdem mal die Suchanfrage offen. Einiges an (alter) Software habe ich schon getestet. Ich plane demnächst auch eine eigene Software für ein Hobbyprojekt zu schreiben. Muss da aber noch einiges planen/klären - insbesondere wie man den 3x3 Cube am besten mathematisch/programmiertechnisch handled.

Es gibt eine ganze Reihe vom solvern, viele quell-offen, da findest du auf jeden Fall Ansätze.

  https://www.speedsolving.com/wiki/index....g_software

Wobei das eigentlich auch nicht so schwer ist wenn du etwas Erfahrung hast. Du brauchst eine struktur/storage format in dem du einen Würfel Zustand abspeichern kannst, und Operatoren fuer die einzelnen moves, welche aus dem Ursprungszustand einen jeweils neuen Zustand (node) erzeugen.

Ein einfache Struktur würde die Würfelseiten beschreiben, du hast 6 Farben, die bekommst du in 3 Bit unter, davon ausgehend dass die Mittelsteine fix sind und sich zueinander nicht verändern können, benötigst du 8 * 6 * 3 Bit zum Abbild eines Zustandes (18 Byte).
Das geht natürlich noch besser, weil jede Fläche ja nicht für sich steht, sondern mit anderen zwingend, als Stein, zusammenhängt (Kantensteine zwei Flächen, Ecksteine drei). Du könntest also auch die 20 Steine und deren Orientierung speichern, was deutlich kompakter ist, aber die Operationen um einen move auszuführen sind komplexer.
Genau die Überlegung hatte ich bisher auch angestellt: Entweder stupide die Farben pro Seite speichern wie Du schon berechnet hast und "einfache" Funktionen für die Moves schreiben.

Oder aber individuelle Variablen für je 8 Ecken mit je 3 Orientierungen und 12 Kanten mit je 2 Orientierungen (8x2bit + 12x 1bit) in einem 3D-Koordinatensystem (3x3x3 array) als Pointer abzulegen, bzw. besser die Position im 3x3x3system stattdessen direkt mit zu speichern. Da Ecken nur an 8 Positionen und Kanten an 12 Positionen sein können, wären auch nur je 3bit zusätzlich für Ecken und 4 bits zusätzlich für Kanten als Positionsmarker in der jeweiligen Variable erforderlich. In Summe also immer 5bit pro Ecke/Kante = 20 * 5bit = 100bit = 12,5byte

Die Move-Funktionen würden dann natürlich wesentlich komplexer ausfallen.



Das ganze plane ich zudem auf einen Microcontroller umzusetzen.
(09.09.2020, 17:07)AstroCuber schrieb: [ -> ]Genau die Überlegung hatte ich bisher auch angestellt: Entweder stupide die Farben pro Seite speichern wie Du schon berechnet hast und "einfache" Funktionen für die Moves schreiben.

Oder aber individuelle Variablen für je 8 Ecken mit je 3 Orientierungen und 12 Kanten mit je 2 Orientierungen (8x2bit + 12x 1bit) in einem 3D-Koordinatensystem (3x3x3 array) als Pointer abzulegen, bzw. besser die Position im 3x3x3system stattdessen direkt mit zu speichern. Da Ecken nur an 8 Positionen und Kanten an 12 Positionen sein können, wären auch nur je 3bit zusätzlich für Ecken und 4 bits zusätzlich für Kanten als Positionsmarker in der jeweiligen Variable erforderlich. In Summe also immer 5bit pro Ecke/Kante = 20 * 5bit = 100bit = 12,5byte

Die Move-Funktionen würden dann natürlich wesentlich komplexer ausfallen.


Das ganze plane ich zudem auf einen Microcontroller umzusetzen.

Auf jeden Fall sehr spannend. Ich hatte das vor 5 Jahren mal gemacht, aber noch simpler und nicht auf einem Microcontroller. Gerade mal nachgeschaut. Ich hatte sehr verschwenderisch alles in ein char array bzw. string gepackt (inkl. Mittelstein). Das initial setup war weiss oben blau (statt grün) vorne.

"WWWWWWWWWBBBBBBBBBRRRRRRRRRGGGGGGGGGOOOOOOOOOYYYYYYYYY";

Aber die moves waren sehr einfach, du musst ja nur einmal statisch hinterlegen wie sich der string bei einem z.B. "R" move transformiert.

Nach einem R sah das dann so aus:

"WWBWWBWWBBBYBBYBBYRRRRRRRRRWGGWGGWGGOOOOOOOOOYYGYYGYYG"

Code:
     WWB              prevmove : R (y30)
     WWB                       depth : 1
     WWB                     nodes : 120

RRR BBY OOO WGG
RRR BBY OOO WGG
RRR BBY OOO WGG

     YYG
     YYG
     YYG

Mir ging es damals darum Fragen zu lösen wie z.B. wie viele moves benötigt man um mit R,Z,R,Z,.... wieder in die Ausgangsform zurück zu gelangen.