# Reachable positions with <R,U>?



## shelley (Dec 23, 2009)

Most of us have done the exercise where we scramble and solve a cube using <R,U>. My question is: given a cube with a 2x2x3 block solved and all edges properly oriented, how can you tell that it is solvable using <R,U> without actually doing any turns on it (i.e. by inspection only)?

If we consider edges only, we can do edge 3-cycles using only R and U, so any edge permutation is solvable. Any corner orientation case is solvable using combinations of Sunes. Therefore the one indicator of whether a position is solvable using <R,U> is the corner permutation. You can't do a 3-cycle of corners using only R and U, but you can swap two pairs of corners. So the position would be solvable if the corner cycle can be solved by doing 2 pair swaps. I'm having trouble figuring out an easy way to determine whether any given cycle can be solved this way though.


----------



## rjohnson_8ball (Dec 23, 2009)

<R,U> cannot flip edges; it cannot solve the parity of swapping 2 corners plus swapping 2 edges (like T, J, N, R, Y, V, F perms).


----------



## Weston (Dec 23, 2009)

rjohnson_8ball said:


> <R,U> cannot flip edges; it cannot solve the parity of swapping 2 corners plus swapping 2 edges (like T, J, N, R, Y, V, F perms).



That doesn't answer the question though.


----------



## iSpinz (Dec 23, 2009)

rjohnson_8ball said:


> <R,U> cannot flip edges; it cannot solve the parity of swapping 2 corners plus swapping 2 edges (like T, J, N, R, Y, V, F perms).



But scrambling with <R,U> cannot give you those algs


----------



## 4Chan (Dec 23, 2009)

If you were to learn how to recognize the 2GLL subset of ZBLL, and solved the remainder of the F2L, you would be able to tell if it was solvable.

Not very efficient, but it's a possibility.


----------



## shelley (Dec 23, 2009)

Yes yes, I know that. But how can you tell by inspection only (i.e. counting cycles)?


----------



## 4Chan (Dec 23, 2009)

Ah, yes yes, you would know that. D:

Forgot who posted this thread for a second there, my mistake. d:


----------



## rjohnson_8ball (Dec 23, 2009)

Maybe I was unclear? I use 3OP for BLD, so maybe this is more obvious to me.

By inspection you can use 3OP "edge flip detection" to quickly identify which of the 7 edges are flipped. (The edge is flipped if <R,U,L,D,F2,B2> would be unable to move the cubie into its correct location with proper orientation. You have to imagine these moves during inspection, but this identification gets easy with practice.) If you have 2 or 4 or 6 edges flipped, then <R,U> will be unable to solve it.

Identify cycles for the corners, as you would for 3OP BLD. If the cycles result in a parity (2 corners and 2 edges would need flipping), then <R,U> will be unable to solve it. In terms of 3OP, such a parity occurs when you see an odd number of cycles that contain an even number of cubies in the cycle. In other words, identify all the corner cycles; ignore the cycles that contain an odd number of cubies but count the number of cycles that have an even number of cubies in the cycle. If the count is odd then <R,U> cannot solve it.


----------



## Sa967St (Dec 23, 2009)

rjohnson_8ball said:


> I use 3OP for BLD, so maybe this is more obvious to me..


 Doesn't Shelley use 3OP for BLD too?


----------



## rjohnson_8ball (Dec 23, 2009)

Sa967St said:


> rjohnson_8ball said:
> 
> 
> > I use 3OP for BLD, so maybe this is more obvious to me..
> ...



See, I am confused. Maybe Shelley switched to M2 or free style or something so long ago that she forgot these 3OP techniques (which I wouldn't expect from a smart person like her)? Or am I missing something?


----------



## qqwref (Dec 23, 2009)

I don't know of any easy way to do this by counting cycles but I'd be interested to see one if it exists. Assuming EO is fine, one other way would be to imagine solving only the corners and disregarding their orientation. Trace the two F2L corners into the solved position and see if that leaves the last layer in the solved position up to AUF; if it doesn't, the position isn't solvable with only 2gen.

rjohnson: it's not at all as trivial as you think. Do an R turn (only).


----------



## shelley (Dec 23, 2009)

First of all, we're ignoring edge flips because those are trivial to determine (see my first post: all edges are oriented properly). In fact, forget the 3x3. Given a 2x2 with two adjacent corners solved, how can you tell that it can be solved in <R,U>?



rjohnson_8ball said:


> ignore the cycles that contain an odd number of cubies but count the number of cycles that have an even number of cubies in the cycle. If the count is odd then <R,U> cannot solve it.



Nope. A four cycle of corners is solvable in <R,U>. A three cycle is not.


----------



## cmhardw (Dec 23, 2009)

qqwref said:


> I don't know of any easy way to do this by counting cycles but I'd be interested to see one if it exists. Assuming EO is fine, one other way would be to imagine solving only the corners and disregarding their orientation. Trace the two F2L corners into the solved position and see if that leaves the last layer in the solved position up to AUF; if it doesn't, the position isn't solvable with only 2gen.



Yes Michael's method of tracing the corners (think speed BLD memo) works to determine if the corners are in a solvable state. This is actually basically my memorization method for <R,U> corners BLD.

I would also be curious if there is a way to determine this by either A) Counting cycles, or B) Looking at the permutation of the UBL, UFR, DBR corners compared to the permutation of the UFL, UBR, DFR corners. Obviously they may overlap each others' orbits, but still I wonder if maybe that could help? I am interested to think on this too.

Chris


----------



## rjohnson_8ball (Dec 23, 2009)

shelley said:


> First of all, we're ignoring edge flips because those are trivial to determine (see my first post: all edges are oriented properly). In fact, forget the 3x3. Given a 2x2 with two adjacent corners solved, how can you tell that it can be solved in <R,U>?
> 
> 
> 
> ...



Oh, wow, I guess I did miss something with the corner stuff. And I didn't see the part about edges oriented properly. Wow, not sure where my mind is.


----------



## Lucas Garron (Dec 23, 2009)

It's pretty clear that the only issue is CP. (EO and C-E parity is familiar).

Somehow I assume a lot more people I've seen it, but then again I've even taken a class that spent 2 days on it...

Anyhow, I already linked Shelley to it, but a lot of you would also benefit from reading Jaap's page.

There should be some reasonable computation to check CP coset, but I'm not exactly inclined to try that right now.


----------



## miniGOINGS (Dec 24, 2009)

Ok, for EO, there is only 1 case (all oriented correctly).

For EP, it's 7*6*5*4*3 (2520) because of the parity restriction.

For CP, it's 6*5*4*3 (360) because of the parity restriction.

For CO, it's 3^5 (243) because of the parity restriction.

So, my calculations give me 220,449,600 positions.


----------



## Tim Reynolds (Dec 24, 2009)

miniGOINGS said:


> Ok, for EO, there is only 1 case (all oriented correctly).
> 
> For EP, it's 7*6*5*4*3 (2520) because of the parity restriction.
> 
> ...



This isn't correct. Did you see the link Lucas posted? You can't get, for an instance, an A perm in <R,U>.

Anyway, it's possible to get odd edge permutation parity and odd permutation parity. For instance, U accomplishes this. For EP there's 7! cases; for CP, you start out with 5!=120, but the parity of the edge permutation and the parity of the corner permutation must be equal, so there are 60 CP cases for any given EP case.


----------



## miniGOINGS (Dec 24, 2009)

Tim Reynolds said:


> miniGOINGS said:
> 
> 
> > Ok, for EO, there is only 1 case (all oriented correctly).
> ...



Hmm, maybe by reducing the CP to 120? That would give us 73,483,200 cases.


----------



## qqwref (Dec 24, 2009)

Hmm. Here's a way to do it based on Jaap's VWXYZ thing:
- Before you start, choose one permutation and memorize the pairs (in terms of which corners are associated with which other corners). You'll also have to memorize the five permutations.
- Now, when you get the scrambled position, just check if your predetermined pairs of corners form one of the VWXYZ permutations. If they are, the position can be solved 2gen; otherwise it cannot.


----------



## Stefan (Dec 24, 2009)

qqwref said:


> Hmm. Here's a way to do it based on Jaap's VWXYZ thing:
> - Before you start, choose one permutation and memorize the pairs (in terms of which corners are associated with which other corners). You'll also have to memorize the five permutations.
> - Now, when you get the scrambled position, just check if your predetermined pairs of corners form one of the VWXYZ permutations. If they are, the position can be solved 2gen; otherwise it cannot.


U


----------



## qqwref (Dec 24, 2009)

Come on Stefan, I expected more out of someone as unbelievably arrogant as you. You should at least make a basic effort to understand what I'm saying before you start flaming my approach. Jaap's page clearly shows how a U and R turn will always transform one of the five permutations into another; for instance, if the corners are now in a V permutation and you do a U turn, they will be in a W permutation.


----------



## Stefan (Dec 24, 2009)

Oh boy, this is really not my day... sorry. I think I did understand you, it's what I had tried myself before, but I had made a mistake and because of that thought it doesn't work and that U is a counterexample. However, I still believe the method isn't quite correct. You'd get 5*3!*2^3 possibilities, that's twice as many as the 120 actually possible ones. So I guess there's still some parity issue in there. Should've used that argument right away, but "U" was shorter.

Edit: Yeah, just swap the two corners of one pair.


----------



## qqwref (Dec 24, 2009)

OK, I see what you mean. Hm, once we've found out that the corners fit into one of the permutations, how do we check if it's got the right parity (what's the 'solved' state to compare to)? Clearly just checking the parity of the corners won't work.


----------



## meichenl (Dec 24, 2009)

It looks to me like qqwref's solution is almost there.

What we need to do, according to Jaap's page, is check that the corner permutation corresponds to a permutation of VWXYZ.

So, to work an example, let's use Jaap's proof to show that U2 R U2 is solvable by R and U. We start by saying that the solved position is V, and ask what the scrambled position is. It turns out to be Y.

Next, we say that the solved position is W, and find that with this assumption, the scrambled position is also W.

Going through and setting the solved position to each of the five pairings, we get

V -> Y
W -> W
X -> V
Y -> Z
Z -> X

this is the permutation

(VYZX)

Since it's a permutation of {V, W, X, Y, Z}, it is a solvable state.

We fail the test if at least one of the pairings does not get mapped to another pairing. For example, consider
the state reached by

U' F' U2 F' D2 F U2 F' D2 F2

This is a 4-cycle of corners, but it can't be solved by a 2-gen algorithm. If the solved state is called pairing V, then this corner permutation doesn't correspond to any of the other pairings, so it fails the condition qqwref set. This shows that some 4-cycles can be solved, but other cannot. I got that position by looking for a 4-cycle that obviously failed to map V into another pairing, and using CubeExplorer to get an algorithm for it.

Now consider switching all the pairs in V by the algorithm

F2 D' L2 U R2 D B2 R2 D' L2 F2 D' F2 D2

This clearly maps V to V, but it doesn't map W onto another pairing. This is why there was the overcount Stefan mentioned regarded qqwref's criterion. There are corner permutations that map some but not all pairings to other pairings.

It's now easy to see that swapping corners isn't allowed. That would leave four corners untouched, which means we'd have to be dealing with the identity permutation, but if we just swapped corners it's obviously not the identity!

We can also see why 3-cycles are disallowed. Suppose we could do an A-perm. Then by doing the A-perm, then a U, we'd have swapped a pair. If the three-cycle is on the R face, it's basically the same argument. If it's split between both faces, it's easy to see by playing with the cube a couple moments that it could be achieved by conjugating an A-perm with one or two allowed moves, so 3-cycles are not allowed.


----------



## qqwref (Dec 25, 2009)

meichenl said:


> This clearly maps V to V, but it doesn't map W onto another pairing. This is why there was the overcount Stefan mentioned regarded qqwref's criterion. There are corner permutations that map some but not all pairings to other pairings.



Aha! That's it. So it looks like checking one of the pairings is not enough, and checking all five is sufficient. I wonder if we can make do by checking fewer than five. I think it might be enough to check 2, actually. Any permutation of the corners that cannot be 2gen'd must be some 2-cycle away from one that is, and we can use 2gen moves (permutations of the five pairings) to move the two pieces that need to be swapped into D. If we switched those corners all pairings would then go to another pairing, so it follows that in the position we have only one pairing (Y) goes to another pairing while the rest go to some pairing that isn't in our set of five. Hence in the original permutation of the corners (any one which isn't solvable with 2gen) only one of the five pairings can be mapped to another of those five pairings.

If that's correct, the method to do this would require you to know the groups of corners formed by two pairings (I suggest X and Y). You would have to check one, and if it didn't match then you would know the position wasn't solvable 2gen, but if it did you'd check the second one to make sure.

Try it out on this one: F2 R2 U F2 U2 L F2 L B2 D R2 D' L B2 L U2


Spoiler



Y works, but X doesn't.


----------

