Incorrect edge orientation calculation?

[Dijabuh]

In RubiksCubeModel.h the UP face is defined as the white face, and is indexed starting with 0. The BACK face is defined as the orange face, and is indexed starting with 32. If we were to try to use RubiksCubeModel::getEdgeOrientation to get the edge orientation of the UP/BACK edge of a solved cube, it first calls getEdgeColors(ind); which returns {this->getColor(1), this->getColor(33)} corresponding to the colors white, orange.

However, when it gets to this check

    // If the U or D sticker is the F or B color (white or yellow), then check
    // the other edge.  If the other edge is the U or D color (red or orange),
    // it's bad.
    if (edge[0] == RubiksCube::COLOR::WHITE ||
      edge[0] == RubiksCube::COLOR::YELLOW)
    {
      if (edge[1] == RubiksCube::COLOR::RED ||
        edge[1] == RubiksCube::COLOR::ORANGE)
      {
        return 1;
      }
    }

The white, orange edge would trigger both if statements and return 1, despite being in a solved state, which should mean that every orientation is 0.

[benbotto]

This is a bit confusing, but not actually a bug (let me know if you disagree). The cube is considered to be oriented correctly when white is the front color and red is the top color. That is, an X Y2 has to be applied to orient that particular model correctly.

This is a project that I've worked on over many years. One of the first parts of the project that I implemented was the RubiksCubeModel. As you mentioned, I defined that as having white on top, red in the front, and orange in back. Later, I implemented a graphical cube separately. When I made the graphical cube (RubiksCubeWorldModel), I defined it as having red on top and white in the front. I don't have a good reason for doing that--probably it's just how my physical Rubik's Cube was sitting on my desk at the time I implemented each--but it makes things confusing. Anyway, when I combined the two projects, I stuck with the latter orientation as being correct, and I just apply an X Y2 to get the RubiksCubeModel oriented like the other two models. (RubiksCubeIndexModel is oriented with red on the top and white up front, like RubiksCubeWorldObject, and there's a comment about the orientation discrepancy in RubiksCubeIndexModel.h.)

Let me know if you still think there's a bug, or otherwise if more clarification is needed.

Here are some notes in the code about the orientation: https://github.com/benbotto/rubiks-cube-cracker/blob/4.0.0/Model/WorldObject/RubiksCubeWorldObject.cpp#L71 (The comment talks about a "solver", but it's referring to the RubiksCubeModel) https://github.com/benbotto/rubiks-cube-cracker/blob/4.0.0/Model/RubiksCubeIndexModel.h#L20

[Dijabuh]

Thanks for the response! Would it be fair to say that it doesn't matter which particular value of 1,2(,3) that you choose for edge and corner cubies to represent the solved state, as long as you are consistent about it?

[JonathanFerron]

You may find the following helpful: http://kociemba.org/math/symmetries.htm

Cheers, Jonathan

---

From: Dijabuh @.> Sent: Wednesday, April 6, 2022 8:40:08 PM To: benbotto/rubiks-cube-cracker @.> Cc: Subscribed @.***> Subject: Re: [benbotto/rubiks-cube-cracker] Incorrect edge orientation calculation? (Issue #4)

Thanks for the response! Would it be fair to say that it doesn't matter which particular value of 1,2(,3) that you choose for edge and corner cubies to represent the solved state, as long as you are consistent about it?

— Reply to this email directly, view it on GitHubhttps://github.com/benbotto/rubiks-cube-cracker/issues/4#issuecomment-1090928919, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARLT7JNVH4ARKW7N5LSYBLLVDYOFRANCNFSM5SXD2KZA. You are receiving this because you are subscribed to this thread.Message ID: @.***>