[Isaev]

Ich habe ein Logikfehler in meinem Programm und kann nicht verstehen was ich eigentlich falsch mache.
Deswegen brauche frische Ansicht von jemandem.
Es geht um Koordinatendarstellung des Wurfels... Ich dachte (bestimmt falsch) dass jeder Wurfelbestandteil im Weltraum sollte auf Ortsvektor und Drehungsvektor eindeutlich ankommen.
zB nehmen wir im 3x3x3 als Beobachtungselement RUF - Eckelement, das zB Koordinaten (2, 2, 0) hat.
Nach R-Zug hat es Koordinaten (2, 2, 2) und wird relative X-Achse gedreht, also Drehungsvektor wird (90, 0, 0)

Und ich habe davon ausgegangen, dass wenn wir Anfangsposition, Endposition und Drehungsvektor haben (aber haben keine Ahnung welche Zuge dazwischen passieren) können wir immer sagen wie (und wo natürlich) sich die Eckelement befindet...

Stimmt das soweit? sieht ganz logisch aus, aber mMn hier ist schon irgendwo ein enigmatischer Fehler drin 

[Apfelkuh]

gibt es Code?

[Isaev]

Es gibt Code, es geht aber nicht ums Code
Code kann ich selbst anpassen, wenn ich es algorithmisch verstehe
die Frage ist: was ich oben geschrieben habe ist iO? dann machen wir weiter)

[Isaev]

Hauptproblem: Nehmen wir wieder RUF-Ecke und Drehen (R B L F)
Der Eckstein kommt zurück zur Anfangsposition, also haben wir keine Koordinatenänderung
Drehungen werden folgend geändert:
nach R(+90 um X-Achse) -> (90, 0, 0)
nach B(+90 um Z-Achse) -> (90, 0, 90)
nach L(-90 um X-Achse) -> (0, 0, 90)
nach F(-90 um Z-Achse) -> (0, 0, 0)
also Eckstein ist auf der Anfangsstelle und haben wir keine Information über Drehungen, sieht so aus, dass der genau so wie beim Anfang steht. Er ist aber im Uhrzeigersinn umgedreht!

wer kann es mir erklären?

PS: so funktioniert mein Code jetzt und er denkt, dass der Eckstein wieder gelöst ist...

[snailcuber]

Er ist aber im Uhrzeigersinn umgedreht!

wer kann es mir erklären?

Du drehst ihn auch im Uhrzeigersinn, wenn du etwas nach vorne kippst, dann drehst und wieder zurück kippst, dann heben sich 1 und 3 nicht auf.

Viel einfacher lässt sich das nachvollziehen, wenn man gleich den ganzen cube rotiert.

 1. X
 2. Z'
 3. X'
 4. Z

[Isaev]

Du drehst ihn auch im Uhrzeigersinn

Na, klar... Das sehe ich... die Frage ist wie kann man das richtig beschreiben (algorithmisch), damit es korrekt funktioniert
Wie muss man Drehewinkel ändern beim R-Zug zum Beispiel?

[ghfreak]

Es sieht so aus, als läge das Problem nicht im Code oder Algorithmus; ich vermute die Koordinatisierung ist nicht allumfassend. Es kann gut sein, dass Stand jetzt nur die Untergruppe der Permutationen der Ecken abgedeckt sind (nur Position der Gesamtecke im Raum beachtet), allerdings muss man sich wie wir gesehen haben auch die Orientierung der Ecken ansehen, die selbst nochmal ne Untergruppe bilden. (Beachte z.B. diesen Artikel: https://en.m.wikipedia.org/wiki/Rubik%27s_Cube_group) Dazu müsste man noch vor dem Algorithmus jedem Sticker eine Bezeichnung geben und dann definieren, dass z.B. „R“ den Sticker x zu Sticker y bringt, wie z.B. hier: http://www.gap-system.org/Doc/Examples/rubik.html

Dabei steht eine Zeile von den sechs (mit den vielen Zahlen) für eine Drehung um 90 Grad und sagt dann mit der Reihenfolge innerhalb der Zykel, was wohin wandert. Dadurch taucht in unserem Beispiel, wenn man Sticker 8 nimmt, der nach deinen vier Drehungen RBLF an Position 25 auf - die Ecke ist im Uhrzeigersinn gedreht

[snailcuber]

Du drehst ihn auch im Uhrzeigersinn

Na, klar... Das sehe ich... die Frage ist wie kann man das richtig beschreiben (algorithmisch), damit es korrekt funktioniert
Wie muss man Drehewinkel ändern beim R-Zug zum Beispiel?

Wie Annika schrieb, es fehlt ein Informationsgrad, du kannst mit deinem System nur das beschreiben was es hergibt. Du könntest dein im ersten Posting beschriebenes Koordinatensystem erweitern. Du beschreibst mit z.B. (2,2,0) die Koordinaten eines Elements, du könntest es um ein Feld erweitern in dem du die Ausrichtung codierst z.B. (2,2,0,1), das wäre dann eindeutig.

[Isaev]

Genau! Danke Allen. Jetzt ist klarer geworden.
Jetzt habe ich eine Idee wie ich alles repariere)