Roux method: An alternate way of solving the last 6 edges

Gabriel Dechichi sent me an email an hour ago, asking a few questions about the last 6 edges. Somehow I misread his email at first and came up with this idea for solving the last 6 edges. It's fairly straight forward, the only real trouble is the recognition I think.

1. Separate edges into the correct top or bottom layer (as well as the centres). I'll call this SL6E (Separation of the last 6 edges)
2. Solve the last 6 edges (and the centres obviously). I don't have a name for this sub step yet.

I think there are at most 216 cases but it reduced down a lot. Here is a list of all possible bottom layer edge situations:

A. Solved (30 cases including solved)
B. FD needs to be flipped (24 cases)
C. BD needs to be flipped (24 cases)
D. FD and BD need to be flipped (30 cases)
E. FD and BD need to swapped (30 cases)
F. FD needs to be flipped, FD and BD need to swapped (24 cases)
G. BD needs to be flipped, FD and BD need to swapped (24 cases)
H. FD and BD need to be flipped and swapped (30 cases)

The C set is the same as the B set + y2/D2. The G set is also the same as the F set + y2/D2. So you can avoid learning 48 algs if you run into a C or G case, by doing y2/D2, a B or F set alg, then undo y2/D2. Also, you can also influence the D layer edges whilst finishing the CMLL, in order to avoid certain cases. But I haven't experimented with this much.

Example solves:

1.
Scramble: M' U M' U2 M2 U' M U' M' U2 M' U2 M2 U M U2 M2 U' M2 U2
SL6E: U' M2
Finish: M' U M' U M2 U M U2 M' U'

2.
Scramble: M' U' M U2 M U' M2 U' M U' M' U' M2 U M' U' M2 U2 M U
SL6E: M
Finish: U' M' U2 M' U2 M U' M' U' M2 U'

3.
Scramble: M2 U2 M U2 M2 U M' U M U' M' U M' U' M2 U' M' U2 M2 U'
SL6E: U M' U2 M'
Finish: M' U' M' U' M U M' U' M' U M2 U M

4.
Scramble: M2 U2 M' U2 M U2 M' U' M' U2 M' U' M U M' U2 M U M' U'
SL6E: M2 U M'
Finish: U2 M' U M' U M' U' M' U M U' M' U'

5.
Scramble: M' U2 M2 U' M U2 M' U M' U2 M U2 M' U M2 U' M2 U2 M U
SL6E: M2 U M
Finish: D2 M' U' M' U2 M2 U M U2 M' D2

Hmm, interesting idea. This is an unexpectedly doable idea - it might be a few more moves than roux style L6E (not sure about this actually, I'd like some calculations) but if you're better at quickly executing algs than lookahead this might well be faster. Have you started generating the algs yet?

Well I generated 5 algs already (for those examples). I haven't bothered with anymore for now. I'm not really sure if it's worth learning or not for advanced roux users. But if someone wants to test it out, I guess we would need to start generating algs. I don't mind doing it if there's enough demand.

this is how i used to solve l6e. Except two look, i put the bottom two edges in the oriantation at the bottom, did oll then pll. And M2 U2 M2 if needed.

Hmmmm I was frowning as I read it until I looked at the examples. It's surprisingly good. I really like the fact it's two looks.

However I think the movecount will be just a little higher than regular LSE, and to practise it up to speed would be very hard to do. anyway, my LSE is somewhat 2 look for me. I reckon this method would be good for those of you who hate step 4b ( ) and those who want to be fast and aren't really fast yet...

Edit: UMD? Why not RUMD? Also D2 can usually be turned in to a d2 then U2 in my experience when I gen algs. I'm not sure whether the same can be done here, cuz centres.

I wonder what the shortest cases for the last step look like... And how often is a first step skip?

interesting.

You could look at this and it might help a little.

Escher said:

I wonder what the shortest cases for the last step look like...

Click to expand...

I'm guessing 7 moves, following the form of M' U* M U* M' U* M. (Ex: M' U2 M U M' U' M)

Seems like it would be really difficult to memorize over 100 algs that all just consist of MU.

Ok I think this kinda is bad or it needs tweaking somehow. I was doing some move counts with Kirjava and Athefre on #rubik and they beat me most of the time. The only times when I beat Kirjava was when edge separation is easy.

I wonder what would happen if you 'separated' to 3 U on U and a U and D on D

5BLD said:

I wonder what would happen if you 'separated' to 3 U on U and a U and D on D

Click to expand...

The first step would be much easier and the second step would be much harder.

Yes. That's what I was thinking. Easier? Hm. You can't just insert D layer edges. Save moves? Maybe.

I was also thinking however that with separation like that the really horrible cases can be just bad. E.g. Pure 4flip vs 4flip+3 cycle
We still have the problem of horrible cases, where you separate *to* a bad case, further wasting moves where if you got it for regular LSE it's not *as* bad. Iduno. When I'm back we can compare movecounts pf regular LSE to this, and weigh up, if there are extra moves, whether it's worth it because it's two look.

Then there's the point regular LSE is already somewhat 2look.

Does anyone have an accurate average move count for the standard Roux LSE?

That is, without special case algorithms.

It's not like there are 'special case algorithms', there are just special cases.

A lot of the forcing LL skip tricks are obvious and should be classed as the standard method.

Most experienced users average around 14 moves in a speedsolve. It's such a low number that it's difficult to beat. I know of only one method that is able to compete.

http://rubikscube.info/lastsix2look.html

Kirjava said:

It's not like there are 'special case algorithms', there are just special cases.

A lot of the forcing LL skip tricks are obvious and should be classed as the standard method.

Click to expand...

Just asking for completion's sake. I am working on my grand unification theory of speed solving method evaluation. There doesn't seem to be a solid average move count reference for LSE:

Frequency of each edge orientation case, and the weighted average for solving step 4a.

Average for the 30 possible positions for 4b

Weighted average for 4c.

I was just wondering about the sub steps as outlined on Roux's page, excluding all the optimization stuff.