Speedcube.de Forum

Hey Leuds,

wer mich persönlich kennt, weiß, dass ich voll auf Methodenvielfalt steh, und deshalb hier ein kleiner Gedanke zu einer Fridrich (CFOP) Variation:

In der Speedsolving-Wiki viel mir bei "experimental Methods" die Methode 3CFCEP auf, mit der ich ohne den Namen zu kennen zuvor schon rumgespielt hab, als ich noch gerade so sub 30 war. Ein halbes Jahr später hab ich mit der Methode meine Offizielle Single-PB rausgehauen, mit 14.53 (in diesem Average hab ich for the lulz 5 verschiedene Methoden verwendet, 16.99 avg5, not worth the joke) . Hier einige Verbesserungen die mir noch gekommen sind, die die Methode als ziemlich effizient darstellen könnte:

Orginal: 3 Cross Pieces lösen , in die vierte Cross Piece Position eine Edge von der U-Layer drehen, Orientierung egal. (im Wikiartikel "Mock Cross" genannt)
Verbesserung: Im besten die Edge UNorientiert in die letzte Cross Piece Position drehen, um einen geringeren Movecount beim Schritt nach dem füllen der Slots zu haben. (Die Stelle nenn' ich jetzt einfach mal "Buffer")

Orginal: Nach dem "F2L" (der Buffer ist noch nicht gelöst) die Ecken orientieren, möglicherweiße mit F2LL Verbunden. Dann Buffer lösen und Edges gleichzeitig orientieren.
Verbesserung: Nach den Slots direkt den Buffer lösen und Edges orientieren (L5E?). Vorteil hierbei: Zeit zum Look-Ahead für COLL (oder sogar ZBLL).

Variante: Zwischen den Slots und Buffer lösen CMLL (Roux Style) verwenden, Vorteil: Weniger eklige Algorithmen, dann Solve mit PLL.

Weitere Gedanken:
- X-Mock-Cross einfacher, da ein Piece des Crosses variabel ist
- besseres Look-Ahead ins F2L wegen einfacherer Planung des Mock-Crosses
- 42 COLL Cases + 4 EPLLs = 46 Algorithmen (Annahme: L5E Intuitiv), vergleichsweiße wenig und gut auszuführende Algorithmen mit chilligem Look-Ahead

Freu mich drauf, eure Gedanken zu hören
MFG
Frieder

Mir gefällt die Idee:

"Zeit zum Look-Ahead für COLL (oder sogar ZBLL)"
Wenn man den Schritt Intuitiv hinkriegt und dabei noch U-Layer Edges lösen oder pseudo-lösen kann, bedeutet das: weniger algorithmen = ZZLL mit leichterer recognition!
Das ist aber nur gut wenn der Edges Teil so schnell geht, dass das ganz am Ende nicht wie ein 2look last layer system mit 200 (beschissenen) Algs ist

Ansonsten ist die Methode mMn so eine kleine Abwandlung von Fridrich/Roux (Warum platziert man jetzt nur eine cross edge falsch, wenn man dann eh nen MU-schritt nach dem F2L hat?)
dass ich sagen würde: "Or you could just use ZZ"

(14.04.2013, 18:37)Petro Leum schrieb: [ -> ]Mir gefällt die Idee:

"Zeit zum Look-Ahead für COLL (oder sogar ZBLL)"
Wenn man den Schritt Intuitiv hinkriegt und dabei noch U-Layer Edges lösen oder pseudo-lösen kann, bedeutet das: weniger algorithmen = ZZLL mit leichterer recognition!
Das ist aber nur gut wenn der Edges Teil so schnell geht, dass das ganz am Ende nicht wie ein 2look last layer system mit 200 (beschissenen) Algs ist

Ansonsten ist die Methode mMn so eine kleine Abwandlung von Fridrich/Roux (Warum platziert man jetzt nur eine cross edge falsch, wenn man dann eh nen MU-schritt nach dem F2L hat?)
dass ich sagen würde: "Or you could just use ZZ"

"(Warum platziert man jetzt nur eine cross edge falsch, wenn man dann eh nen MU-schritt nach dem F2L hat?)"
==> Weniger Fälle, einfacher auzuführende Algs, man muss nicht auf die UD Edge schauen oder ausschlussverfahren anwenden.

Und: Das mit dem ZZLL war eher n Hirnfurz, hab ja selbst keine Ahnung von der Anwendung und Caserestriction von ZZLL, mein Ziel war eigentlich eher COLL und Look-Ahead zu COLL, L-A zu Last Layer Edges Fällen wird sauschwer an der Stelle :/

(14.04.2013, 18:52)Frieder schrieb: [ -> ]"(Warum platziert man jetzt nur eine cross edge falsch, wenn man dann eh nen MU-schritt nach dem F2L hat?)"
==> Weniger Fälle, einfacher auzuführende Algs, man muss nicht auf die UD Edge schauen oder ausschlussverfahren anwenden.

1. einfacher auszuführender Algs? du meinst, weil die algs dann immer so M' Ux M Ux M' Ux M aussehen? finde ich nicht schöner.
2. Du musst ncith auf die DB Edge schauen, weil du sie im MockCross geplant hast. immerhin musst du alle Crossedges planen, weil du keine F2L-Edge drin haben willst, du sparst dir nur Züge weil du 4 Edges mehr zur Auswahl hast.

(14.04.2013, 18:52)Frieder schrieb: [ -> ]Und: Das mit dem ZZLL war eher n Hirnfurz, hab ja selbst keine Ahnung von der Anwendung und Caserestriction von ZZLL, mein Ziel war eigentlich eher COLL und Look-Ahead zu COLL, L-A zu Last Layer Edges Fällen wird sauschwer an der Stelle :/

Es ging mir vor allem darum, dass es geil ist, die Recognition eines LL-Falls als Lookahead in einen früheren Schritt einzubinden. Ich liebe es schon immer so, wenn ich als COLL-Noob Roux mache, beim CMLL (bzw halt COLL) part schon mein LSE planen kann

Also dein Vorschlag ist:
1. Mock Cross
2. F2L - buffer
3. EO + buffer
4. COLL
5, EPLL
richtig?

Hab selbst schon mit ähnlichen ideen rumprobiert, auf jeden Fall gefällt mir die Idee, einen MU Schritt vor CxLL reinzuhängen

Wie ist denn der average movecount für eo+buffer lösen?
~7 STM?

(14.04.2013, 22:59)pijoka schrieb: [ -> ]Wie ist denn der average movecount für eo+buffer lösen?
~7 STM?

Also mit meiner Variation ein NICHTorientierte WEIß enthaltende Edge im Buffer zu haben sind es entweder 7 oder 11, mit 50:50 chance.
Wenn es eine NICHTorientierte beliebige ist, ist der STM bei etwa 6, da man manchmal eine 3 Move Lösung hat.
Bei beliebiger Orientierung ist der STM höher... meiner Meinung nach nicht lohnenswert, zu viele Fälle, zu lange Lösungen.

(15.04.2013, 14:03)Frieder schrieb: [ -> ]Wenn es eine NICHTorientierte beliebige ist, ist der STM bei etwa 6, da man manchmal eine 3 Move Lösung hat.

Okay, ich dachte Du machst das so

(15.04.2013, 14:03)Frieder schrieb: [ -> ]Also mit meiner Variation ein NICHTorientierte WEIß enthaltende Edge im Buffer zu haben sind es entweder 7 oder 11, mit 50:50 chance.

Du machst also gar kein mock cross sondern nur ein cross bei dem eine kante falsch orientiert ist?

(15.04.2013, 14:03)Frieder schrieb: [ -> ]Bei beliebiger Orientierung ist der STM höher... meiner Meinung nach nicht lohnenswert, zu viele Fälle, zu lange Lösungen.

Wenn man es sowieso intuitiv macht ist die Anzahl der Fälle fast egal und ich glaube nicht dass es allzuviel ausmacht

Zum lösen der letzten 5 Kanten brauchst Du also im Schnitt ca 15 Züge. Das ist meiner Meinung nach etwas ineffizient. Zum Vergleich: Bei Roux schafft ein guter Solver 6 Kanten + Mitten in 15 Zügen.

Im Vergleich zu CFOP hast Du ein etwas vereinfachtes Cross, nimmst dafür aber einen 3Step LL in Kauf (EO, COLL, EPLL). Meiner Meinung nach nicht allzu lohnenswert.

Für 46 algs ganz ok, kann aber IMO nicht mit Roux mithalten

Roux ist das wahre ich weiß
Auch Blockbuilding hat natürlich was für sich... aber mich hat an 3CFCEP gereizt n geiles x-mock-cross zu planen und dann geniales coll-look-ahead zu haben... bei roux hat mich der L5E look-ahead-bezüglich gestört... wär aber mit übung bestimmt weggegangen