[DaCuba]

Hey,
Grad mal nen bissl über den Würfel nachgedacht

Jeder weiß: Wenn ein Algo x mal hintereinander ausgeführt wird, geht der Würfel wieder in den gelösten (bzw Ausgangs-) Zustand über.

Meine große Frage: Warum ist das so?
Funktioniert das wirklich mit jedem Algo,. also auch mit Scrambels?

Weiß jemand wo es nen kleinen Beweis dafür gibt? (Das würde mich am allermeisten interesserien)

gruß

[LinusR]

Ich denke du musst selber einne beweis finden. Wieso: Weil man ja quasi einen algorithmus ausführt der die steine permutiert wie bei blind auhc mal so das er nicht mehr orientiert ist aber wenn man einen Pll oder scramble ausführt und das mehrere male dann permutiert man solange bis man an die stelle kommt wo der algo der god's algo ist. (auch wenn scrambles länger sind)
z.B. Kante UR (das vordere in dem fall U ist der sticker der mit dem nächsten vorderen taushct) kommt an den platz UL und die an die stelle von UF und die an UR (U-perm). Wenn man den scramble( ich habe u-Perm genommen weil es einfacher ist) nun einmal aus führt kommt man in die inverse Position von dem was der scramble löst (es gibt eine fewest moves methode die nach ungefähr mdeisem prinzip arbeitet, sie heißt NISS) wenn wir den scramble jetzt noch einmla ausführen vertauschen die gliechen positionne aber nicht di eselben steine. der stein der vorher(am anfang) auf UF war ist nach dem man den scramble das erste mal ausgeführt hat in der nächsten position des cycles(UR) und nach dem man den scramble noch einmal ausgeführt hat kommt der stein der anfangs auf UF war auf die nächtse position des cycles (UL) und ist nahc dem scramble beim nähcsten ausführen des cycle wieder an der anfangs position da der cycle zu ende ist. (Ich hoffe das es richtig und hilfreich ist ( so habe ich mir das immer vorgestellt klärt mich auf wenn ich falsch liege))

[NicoS]

Den folgenden Text bitte komplett lesen, sonst verbreitet er Lügen (so vielleicht auch, aber er klingt auf jden Fall sinnvoller )

Ich habe es mir folgendermaßen vorgestellt:
Jeder Alg tauscht x Kanten (ein x-Cycle) und y Ecken (y-Cycle).
Jetzt dauert es natürlich x Ausführungen bis die Kanten wieder gelöst sind und y bis die Ecken passen.
Nimmt man nun das kleinste gemeinsame Vielfache der beiden kommt man auf die Anzahl der nötigen Ausführungen, bis man wieder in der Ausgangsposition ist.
(Dem aufmerksamen Mathematiker ist ein ganz elementarer Fehler aufgefallen und zwar folgender:

Spoiler (Click to View)

Hat man bspw. einen 0-cycle bei den Ecken, kann man kein kleinstes gemeinsames Vielfaches bestimmen

Ob das wirklich so ist, weiß ich nicht, von der Permuation dürfte es stimmen, ob es auch für die Orientation passt weiß ich nicht, man könnte es aber leicht mit z.B. Sune überprüfen...

Was ich natürlich auch gemacht habe

Sune vertauscht 3 Kanten (3-cycle) und 2 Ecken (2 werden diagonal vertauscht[<-Fail aber ich korrigiere es noch]) und demnach würde es stimmen. Hier gibt es aber ein Problem, es ist nämlich eigentlich unmöglich nur 2 Ecken zu vertauschen (außer wie in diesem Fall per Orientationsänderung), weshalb natürlich ein weiter Test her muss

Testobjekt: RUR'U' oder im Volksmund "Der Sexy Move"
Kanten 3-Cycle
Ecken 2 2-Cycle (Einer zwischen den Ecken URF und RDF und einer zwischen UBR und ULB)
Hier haben wir 2 Ecken-Cycle, was aber nicht weiter schlimm ist, da immer nur die jeweiligen "Cycle-Ecken" vertauscht werden und es dementsprechend wieder mit mit der oben genannten Regel hinhaut.
Während ich diesen Absatz geschrieben habe, ist mir aufgefallen, dass bei Sune auch 2 2-Cycle vorhanden sind, aber naja ich darf auch mal Fehler machen

Aber anscheinden passt meine Theorie und es kommt nur auf die Größe der Cycles an, jedoch von jedem Cycle also auch von mehren Ecken/Kanten-Cycles falls sie vorhanden sind (was auch das Problem der 0-Cycles löst)
Als Abschluss Satz würde ich folgenden nehmen:
Überprüfe alle deine Cycles, bestimme ihre Größe und bilde das kgV zwischen allen Werten!

[LinusR]

mist deins ist ausführlicher aber ich war schneller

[DaCuba]

Danke für die Beiträge

Alle Antworten machen schon Sinn, und Mezzos ist am einfachsten zu verstehen, macht ehrlich gesagt aber auch am meisten Sinn
Ist schon ne coole Sache das ganze gell? ;D

Wer noch mehr so Ansätze hat kann sie natürlich auch posten, aber ich hatte bis jetzt noch keine Idee^^

[Logen]

Ich denke jede Zugfolge (oder scramble etc.) Orientiert und permutiert immer die gleichen steine also muss jeder Stein wieder an seine Ausgangsposition kommen wenn man immer die gleiche Zugfolge macht.

[Logen]

Es geht nur es dauert ziemlich lange (ich habe es bisher 2 mal gemacht und es hat ewig gedauert und bei 50 hatte ich aufgehört zu Zählen)

[NicoS]

Ich verstehe deine Aussagen und sie decken sich ja auch mit meinen Ergebnissen/Vermutungen, jedoch habe ich ein Problem:
Du sagst ein sich drehender Stein zählt als 3-cycle (verstehe ich auch voll und ganz, wie du da rein-logisch draufgeommen bist, hätte ich wahrscheinlich auch so gesagt), aber ich habe mal mit SetupMoves und so weiter ausprobiert, ob man denn dann mit einem A-Perm (3-cycle) irgendwie nur 2 Ecken vertauschen kann, habe es jedoch erwartungsgemäß nicht geschafft.
Jetzt drängt sich ja die Frage auf, warum das ein 3-cycle ist und nicht 2 2-cycle (hin, drehen, zurück)

Wie gesagt es macht Sinn, wenn man logisch denkt (15:3=5, 5 Ecken, jede wird nach 15 Wiederholungen 3 mal gedreht), aber ich schaffe es partout nicht, das ganz mit einem simplen A-Perm darzustellen.

Wenn das einer schafft, soll er es bitte posten, bisher kann ich die Sache nur glauben, ich würde sie aber gerne wissen (und außerdem würde das heißen, das meine Annahmen richtig waren )

[NicoS]

A-Perm: 3-cycle
1 Ecke dreht sich (und natürlich damit auch einer ander): Auch 3-cycle (zumindest nach deiner Theorie, welche ich auch für richtig halte^^)
Nur jetzt würde ich gerne sozusagen als Beweis mit einem A-Perm 2 Ecken drehen

[NicoS]

Ich spreche von 2 verschiedenen cycles, einen beim A-Perm und einem beim Eckendrehen^^
Und ich würde gerne mit einem A-Perm 2 Ecken drehen (natürlich ohne Permutationsänderung)