L2L4 - The Lost Methode ? Help Find it!

[riffz]

So would it be good to standardize the order that you solve the E slice edges? And if so, what would be the ideal order to solve them in? I'm thinking BL/BR while solving corners to make the last 2 steps really easy to recognize.

I'm just not sure whether setting a fixed cube orientation would help recog/speed at all.

EDIT: NVM. I suppose a few cube rotations is a good trade-off having to learn a bunch more cases

 

[nickvu2]

Me too. I also did a pretty minor start at #30 in this threat.

Where/How should we collect our results?
Wich process do we use do identify the 'good' algs from all the possible ones?

I just started a Google Doc to collect our work. We can use it or not, just wanted to get the ball rolling. I set it so that anyone with the link can edit it, which means everyone here.

To find good algs, I eyeball a few on Cube Explorer that look nice then do an avg of 12 for each to determine which is fastest.

 

[nathanajah]

I don't understand what you are talking about. What?

To look ahead clearly, you have to reduce your turning speed,since at max speed it's hard to search for the next pair (CMIIW)

 

[FatBoyXPC]

Thom, how did you come up with 90 algs?

 

[nickvu2]

Ok, do I have this right?
CO: (8 sets) T, U, L, H, Pi, Sune, anti-Sune, solved
CP: (5 sets) A(a), A(b), T, Y, solved
EO: (4 sets?) no edges, opposite edges, adjacent edges
EP: (4 sets?) U(a), U(b), Z, H

I'm pretty sure the edge steps are wrong, the placement of the E-slice edge in the LL would result in all sorts of other sets. Can anyone classify these for me?

And then how many cases would be in each set? For CO, would it be 8 cases since there are 8 positions where the first E-slice edge could be? (Even with the edge solved, you'd still have to orient corners.) Then 7 cases for each CP set, 6 cases for each EO, and 5 for each EP. But then symmetry? I'm going to stop speculating now. Please set me straight!

 

[oll+phase+sync]

I "completed" the CO doublesune Toplayer Case in the google doc.
That is the easierest because of U2 Symetry ist just 4 Cases (2 when not countig mirrors)

There are 8 more cases if all medges are already in the middle layer - But this is rare happens and sould maybe handled differntly?

I use Josef Jelineks ACube PRogramm is there a tutorial on the web? Else I really recommend reading the manual it's great and fast.

But I also regognised that some gems may get overlooked by just using a programm (that not really manages r u f ... moves)

first "little" Gem List:

uSune: RUR'uRU2R'
llittle Nikllas: RUl'U'R'Ul
clllix: x' RUl'U' R'UlU' x

I also proposed a naming System in the google doc - Quiz find: the right names for these gems?

 

[FatBoyXPC]

Ok, do I have this right?
CO: (8 sets) T, U, L, H, Pi, Sune, anti-Sune, solved
CP: (5 sets) A(a), A(b), T, Y, solved
EO: (4 sets?) no edges, opposite edges, adjacent edges
EP: (4 sets?) U(a), U(b), Z, H

I'm pretty sure the edge steps are wrong, the placement of the E-slice edge in the LL would result in all sorts of other sets. Can anyone classify these for me?

And then how many cases would be in each set? For CO, would it be 8 cases since there are 8 positions where the first E-slice edge could be? (Even with the edge solved, you'd still have to orient corners.) Then 7 cases for each CP set, 6 cases for each EO, and 5 for each EP. But then symmetry? I'm going to stop speculating now. Please set me straight!

I'm going to go ahead and mention that we all know that solved counts as a state, so I won't bother to mention that as a "set." You got CP wrong though, it's only 3 cases. Aa, Ab, and E.

As for how many in each set, I feel like I missed some. Seth Hovland and I have been discussing this, and we've both put some thought into it. I'm thinking that if we used d/d' to be a "setup move" we could start with 8 algorithms for each of the 4 LL steps. I say this because you 4 edge positions in the U layer, and 2 orientations for each position. There is also the problem when there are no edges in the U layer that belong to the E slice. There is also the issue where the edge is solved but flipped. I'm guessing with that case the algorithms to flip it would be just a few moves different than the algorithm to remove the edge from a given slot. With this "setup move" method we won't have to make it so every algorithm shoots to the same target (such as FR). I do think that the algorithms should shoot to FL/FR to allow for easier look ahead though (note that if you shoot to BR/BL then it's just a mirror for FR/FL). I also think we should find some sort of standard to map the target edge locations from each algorithm so that we don't have to also remember what it's target is. I'd say using d/d2/d' is quite a tradeoff for learning three times as many algs (but mirrors would then cut down on that).

We could also eliminate the EO step altogether by orienting the edges appropriately after the first layer using F SM F'. This would leave us with the standard U/H/Z algs at the end, though.

Edit: It appears as though a chunk of what I just said is already in this Google document

 

[aronpm]

I'm going to go ahead and mention that we all know that solved counts as a state, so I won't bother to mention that as a "set."

If CO is solved you still probably have to insert the edge.

 

[onionhoney]

Actually i think the most difficult step is to make a layer, because in order to become fast, you have to finish it in 2~3 seconds.

 

[FatBoyXPC]

Aron: Doh! I forgot to include that, but that was brought up when Seth and I were thinking about it I would probably continue to CP/EO/EP at this point though. Depending on how the algorithms we make affect the cube (I'm guessing that we'll make a standard of either CO/CP/EO/EP or EO/EP/CO/CP) and the algs will become longer and affect less of the cube further down the line we go. If we were to include say just a CP alg that inserts an edge and doesn't affect anything but EP, we could just do the EP alg to insert the edge and then do a standard EPLL alg to solve the cube (U/H/Z). This way we won't have to make an alg for each OCLL, CPLL, EOLL, and EPLL. We'd only have to make it for each EPLL. I guess it'd be easier to make it with the EOLLs since there are only 3 cases of those

onion: I think that if people started concentrating on building a first layer less LBL style and more blockbuild type, we'd see first layers in 3 seconds without a hitch. Not to mention that some fast cubers (Rowe, Feliks) can F2L in 3-4 seconds, imagine if they didn't have to worry about edges LBL F2L can be completely rotation-less, so that also helps with speed.

 

[oll+phase+sync]

If CO is solved you still probably have to insert the edge.

Hope I don' repeat someone else; but CP has Only 3 cases. Though I hope there are cool options for "double" shots. Also an R2ER2, F2EF2,... like Sub step befor or after CO is not so bad I believe.

 

[oll+phase+sync]

CP Step - no time for googledocs this time will be away for the next week

Solved
M' U R' U' M U R UB -> BR

Diagonal
F2 U'RU' R'U F2 URUR' places UB -> FR / UL -> FL

One Line:
R2 F' R U' F' U2 R2 U' R' F


But the number of cases is higher as I thought, because you will need to position our edge next (left right) to an already positioned edge


CO Step
Maybe it would be better to alwas align an medge in th top layer to its center and place these right.
Now there are just 2 taret Spots FR , BR and 4 U-shifts of the orientation pattern.

this would make 7 *4 *2 cases Doublesune case only has 4 cases wich makes 52 cases

But the Fact that the edge is at UR means that each case has on Mirrord case so its only 26

 

[jms_gears1]

[disclaimer] this may have already been said but i didnt see it, or if not it could just be something stupid that doesnt need said[/disclaimer]

Ive noticed that one alg for the CO step can be used for a bunch of different cases.

On a solved cube do:
Ru2R'u'Ru'R'
Doing the inverse of this alg would solve CO plus: FL, BR, or BL

also for CO step, wouldnt there be a LOT of cases if you do it first?

you have four possible AUF's of the OCLL and you have 4 possible places the edge you need could be, with two orientations of that edge.
Wouldnt the number be 4*4*2 or 32 cases for each OCLL case?

 

[cincyaviation]

[disclaimer] this may have already been said but i didnt see it, or if not it could just be something stupid that doesnt need said[/disclaimer]

Ive noticed that one alg for the CO step can be used for a bunch of different cases.

On a solved cube do:
Ru2R'u'Ru'R'
Doing the inverse of this alg would solve CO plus: FL, BR, or BL

also for CO step, wouldnt there be a LOT of cases if you do it first?

you have four possible AUF's of the OCLL and you have 4 possible places the edge you need could be, with two orientations of that edge.
Wouldnt the number be 4*4*2 or 32 cases for each OCLL case?

The edge just needs to be shot to a position, say, FR, so you could just position it so that the edge's spot is at FR, i think it's something like 9 cases per OCLL if you always have an E edge in the U layer.

 

[Joker]

I don't really see how you look ahead with this method.

 

[cincyaviation]

I don't really see how you look ahead with this method.

Why would you need to?

 

[qqwref]

This is an algspam method. Apart from tracking the next E edge to place, you probably don't need to and can't look ahead.

 

[jms_gears1]

The edge just needs to be shot to a position, say, FR, so you could just position it so that the edge's spot is at FR, i think it's something like 9 cases per OCLL if you always have an E edge in the U layer.

I feel like an idiot now :fp

 

[FatBoyXPC]

qqwref: Does that not count as lookahead though?

oll+phase+sync: Only 2 CPs: T and Y.

For fixing a flipped edge, you could use two already known algs (though this is inefficient). You could also make only one edge flip alg and use that alg to fix a flipped edge. I could make an edge flip alg for all 4 steps and find the fastest to execute and use it regardless of what step I was on (but I'd probably ignore the flipped edge until I got to that step anyhow).

 

[cincyaviation]

qqwref: Does that not count as lookahead though?

oll+phase+sync: Only 2 CPs: T and Y.

Ahem, solved...