[AstroCuber]

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

[AlexICG]

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

[AstroCuber]

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.

[snailcuber]

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.

[AstroCuber]

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.

[snailcuber]

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.

[AstroCuber]

Mal ein Update meinerseits: Ich habe nun, da ich es doch für den leichtesten Weg hielt, einfach Deine Methode übernommen: Die 54byte RAM sind für einen modernen Microcontroller einfach nur lachhaft. Der Mikrocontroller ESP32, den ich dazu einsetze, hat laut wikipedia 160kiB RAM. Mein Board (wemos lolin32) hat zudem 4MB Flashspeicher und 240MHz-Taktung. Das ist doch ein Vorteil moderner Zeiten: Die sparsame Programmierung aus den 90ern mit PIC16 sollte ich mir dringend abgewöhnen. Dank Wifi und Webserver-Steuerung kann man auch vollkommen auf Hardware-Bedienung verzichten und alles bequem per Smartphone steuern.

Die Moves habe ich mit Hilfe einer mathematischen Abbildung allerdings nicht einfach hinbekommen, weshalb ich sie erst mal einfach als Zeichenketten Umsortierungen umgesetzt habe. Bsp:

Code:

// cube format:  down    left      back    right    front    up
char cube[] = "wwwwwwwwwrrrrrrrrrbbbbbbbbbooooooooogggggggggyyyyyyyyy";
//             012345678901234567890123456789012345678901234567890123
//             0         1         2         3         4         5

void half_R(){
char memo;
//first step: rotate right face
memo=cube[27];
cube[27]=cube[30];
cube[30]=cube[33];
cube[33]=cube[34];
cube[34]=cube[35];
cube[35]=cube[32];
cube[32]=cube[29];
cube[29]=cube[28];
cube[28]=memo;
}
//wwwwwwwwwrrrrrrrrrbbbbbbbbbooooooooogggggggggyyyyyyyyy
//012345678901234567890123456789012345678901234567890123
//0         1         2         3         4         5

void third_R(){
char memo;
// second step: rotate right column
memo=cube[38];
cube[38]=cube[41];
cube[41]=cube[44];
cube[44]=cube[2];
cube[2]=cube[5];
cube[5]=cube[8];
cube[8]=cube[24];
cube[24]=cube[21];
cube[21]=cube[18];
cube[18]=cube[47];
cube[47]=cube[50];
cube[50]=cube[53];
cube[53]=memo;
}
//wwwwwwwwwrrrrrrrrrbbbbbbbbbooooooooogggggggggyyyyyyyyy
//012345678901234567890123456789012345678901234567890123
//0     

..
..
..

void(*mvptr[])(void) = {
  half_R, third_R,
  ..
  ..
  ..
}

void animv(int motion)
{
int slot=anitime/6;
(*mvptr[motion])();  // half motion face
(*mvptr[motion+1])();  // third motion row
displaycube();
delay(slot);
delay(slot);
(*mvptr[motion+1])();  // third motion row
displaycube();
delay(slot);
delay(slot);
(*mvptr[motion+1])();  // third motion row
(*mvptr[motion])();  // half motion face
displaycube();
delay(slot);
delay(slot);
}

#define R  0
animv(R);

Ich habe mir einen (starren, nicht drehbaren) Cube mit 54 RGBW-Leds aufgebebaut, der darüber gesteuert wird.
Von Solve-Funktionen bin ich allerdings noch weit weg. Dafür muss ich die Grundstruktur vermutlich noch mal komplett überarbeiten.
Demo-Modus (zufällige Moves) / Scambeln oder manuelle Einzel-Moves über Web-Steuerung gehen aber schon.

[snailcuber]

Das sieht sehr ähnlich aus. Ich bewahre allerdings jeden errechneten "node" in einer verketteten Liste auf, so dass ich einfach vom previous node auf den neuen inkl. der Transformation umkopieren kann. Da ist es dann auch einfach auf ein paar moves zu brutefocen, wenn der Zuggenerator (der einfach alle möglichen moves errechnet) auf eine bereits bekannte Stellung trifft, dann muss die ja nicht weiter verfolgt werden. Wenn man die nodes aus diesem Grund aufbewahren muss, dann ist ein komprimiertes package format natürlich von Vorteil.

Wenn man die Lösung in einzelne Meilensteine aufteilt, dann war damals meine Hoffnung, das zwischen diesen Meilensteinen brutefoce möglich ist. Angefangen mit dem cross, hier reicht eine Tiefe von 8 um die beste Losung zu finden.

Siehe auch :
http://www.cubezone.be/crossstudy.html

Von dort aus dann weiter zum nächsten milestone (der muss so gesetzt werden dass er zur Rechenpower und Memory passt), komplett F2L wird wahrscheinlich viel zu viel sein.

So weit bin ich dann nie gekommen, andere Themen waren wichtiger. Aber gerade habe ich mich wieder
reingesteigert, an Mikrocontrollern habe ich hier noch ein paar ältere Arduinos rumliegen, die hatte ich für
einfache Steuerungsaufgaben genommen, sind aber wohl nicht mehr so zeitgemäß, an RAM haben die
(glaube ich) 2 KiB. Aber die waren schön bequem, einfach per USB anschließen, kein extra Programmiergerät.

[AstroCuber]

Mal eine kleine Ergänzung, bzw. mal ein Schritt zurück: An einer Lösungs-Software habe ich bis dato nicht weiter gearbeitet. Dafür habe ich jetzt endlich eine gute Quelle für CFOP-Lösungen (und andere) gefunden, die man auch gleich step-by-step mit ein Klick "durchwalken" kann:
https://speedcubedb.com/r/index
Hier werden von fleißigen Helfern Solves anhand von Videos rekonstruiert, u.a. von vielen sehr bekannten Cubern. Es ist doch erstaunlich, wie unterschiedlich CFOP-Solves doch sein können.

Anschauenswert ist auch die Arbeit der statistischen Auswertung und Aufbereitung tausender Solves von Basilio Noris: Learning from the Pros https://basilio.dev/cubing/recons/ReconStats-v0.pdf

[snailcuber]

Beides super interessant, vielen Dank für die Referenzen! Mit sowas kann ich mich stundenlang beschäftigen, auch wenn es wahrscheinlich wenig praktischen Einfluss auf meine cubing Fähigkeiten hat.