Rotations/wide turns for non-inspection events

[lgarron]

That is, for BLD scrambles. I suggest the appending the following to every 3BLD scramble:

• Randomly select a move from {id, Rw, Rw2, Rw', Fw, Fw'}
• Randomly select a move from {id, Dw, Dw2, Dw'}

This is simple to understand (put a random center on U, then put a random center on F), allows the scrambler to keep the same centers on top and front for the most of the scramble (a useful crutch if you briefly lose track of orientation), is easy to prove correct, and doesn't require changing the solver.

The moves should be considered part of the scramble. That means that scramble filtering should be done on the result, and the resulting image should include these moves.

For 5BLD, these moves should be 3 slices wide (3Rw, 3Rw2, etc).
For multi BLD, all cube scrambles should be independently and oriented (although the same for every competitor).

For 4BLD, there is no fixed corner. Could someone (@chenshuang, @clementgallet?) confirm that we don't need to do anything, i.e. that the 4x4x4 scrambler produces a random permutation of corners, wings, and center without requiring any further orientation?

[lgarron]

Proof of correctness: A random top center and random front center means that the centers are a random non-reflected symmetry. Given a fixed suffix for a particular translation between centers, every permutation with this center orientation maps to exactly one with the original centers, so the full state is random.

[pochmann]

Shouldn't you also prove that each orientation is equally likely?

If you're appending extra moves rather than changing existing ones, then
why not just use x/y/z? Shorter, more usual, makes the purpose more
explicit, and the filtering doesn't have to care about it.

[lgarron]

Yes, that's the first sentence of the proof (just corrected a typo, though).

This came out of a Delegate discussion.
In an ideal world, x/y/z should be fine. However, scramblers are more likely to be confused/mistaken about x/y/z, and are more likely to ignore such rotations. (I'm realistically concerned about the following train of thought: "The first cube I scrambled had this pattern on the back before I performed the rotations, and this one looks the same, so I know it's fine without doing the rotations. And since it might get flipped on the way to the competitor, I feel like it doesn't matter. It doesn't even change the scramble (s)he gets.")

[jfly]

On Dec 27, 2013 8:28 AM, "Lucas Garron" notifications@github.com wrote:

That is, for BLD scrambles. I suggest the appending the following to
every 3BLD scramble:

Randomly select a move from {id, Rw, Rw2, Rw', F2, Fw'}

Should the last 2 be Fw' and Fw? I don't see what F2 does for us :-)

Randomly select a move from {id, Dw, Dw2, Dw'}

This is simple to understand (put a random center on U, then put a random
center on F), easy to prove correct, and doesn't require changing the
solver.

This implementation sounds nice and easy. It just annoys me a bit that
we're making our beautiful scrambles longer. I'd like to look into coming
up with a solution that doesn't make the scramble longer by cleverly
replacing existing B's with Fw and D's with Uw.

EDIT: I thought about this last week (around New Years), and decided this was a bad idea for two reasons:

1. What I wanted to do is impossible in the general case. Consider the scramble R U2. It's impossible to munge that scramble in a way such that the D face will end up on top.
2. Lucas argued that always putting wide turns at the end of a scramble is better because it's consistent.

[lgarron]

@chenshuang, @clementgallet: Poke on confirming that the 4x4x4 scrambler is random-orientation without further changes.

[cs0x7f]

It's random-orientation but I cannot prove that each orientation has the same probability as the orientation is depend on the reduction procedure.

[lgarron]

Right, which is why I suggested: Place a random center on U, then place a
random center on F (keeping the one on U). This uniquely determines each
orientation with equal probability.

EDIT: Were you talking about my proof for 3x3x3 (which is what I thought), or about the 4x4x4 scrambler?
EDIT 2: I think you were probably talking about 4x4x4. In that case, we need to randomize corners (everything else will stay random through bijection if we're careful).

[lgarron]

@smakisumi Could we have a mathematician in the house to check my 3x3x3/5x5x5 "proof"?

[sivashanmukh]

If we have a problem with fixing two faces, why don't we just use two adjacent corners to keep it uniform for nxnxn type cube scrambles for all n we support?
http://crazyproject.wordpress.com/2010/01/09/a-cube-has-24-orientation-preserving-isometries/
This and the using two faces like Lucas suggested can be reduced into each other.

[smakisumi]

Lucas's proof for equal probability is correct.

[lgarron]

After discussing this with Jeremy, the plan for 4x4x4 will be to add rotations to the end of the solve. It's very clear that this does work, and avoids subtle issues that don't allow the 3x3x3 trick to work if we don't have a fixed component in the 4x4x4 scrambles.

Since 4x4x4 BLD is scrambled less often, this shouldn't be as much of a trouble.

Siva: I'm not sure what you're trying to say?

[jfly]

444ni has been done here jfly@5021729. Closing this issue.

[pochmann]

I'm not convinced this is correct for 4x4x4. Any bias in the LwDwBw part (the pieces not affected by Rw, Uw and Fw moves) will remain, and we seem to be uncertain about such biases.

[jfly]

I don't see how there could be any biases in that block. Perhaps I'm missing something subtle with the fact that 444 has multiple pieces that look exactly the same?

I'm reopening this issue. @lgarron, could you convince Stefan we're ok here, or figure out what we need to do to be ok?

[lgarron]

Perhaps Stefan, like I, was confused about new CubeMove(Face.F, 1/2/3, thickness) looking like a block turn instead of a rotation?

The generated scrambles appear to do the right thing.

[jfly]

Closing this as I believe we did everything required here for the 2014 regulations. Feel free to reopen if necessary.