• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

L2L4 - The Lost Methode ? Help Find it!

Misplaced edges will be brought into the U layer as you place edges in the correct slots.

Haha...wow, that was easier than I thought. I guess you would need a backup alg to extract an edge in the off chance they're all in the E slice, or if for example FL and FR are swapped.
 
I guess I'm just confused about something. If we swap UF/FR (and it doesn't matter what happens to UL/UB/UR permutation wise), we'll just end up with a standard EPLL (Ua/Ub/H/Z).
No, you won't. I've said before, doing a 2-cycle from a valid position leaves you in an INvalid position, so you'll get a parity EPLL. Look:
- setup with R2 U R' U' R' U' R' U R U2 R U R U' R' U' R' U' (I know it's long I just made this up)
- do the 2 swap with R' F2 B2 [T perm] F2 B2 R, ignore the two corners on D
Now, see? You DON'T have an EPLL on the U layer. You actually have a W perm (UF -> UR -> UL -> UB).
 
Are you able to hop into #rubik?

Edit:
Apparently you went to bed soon after this post. The reason I asked is so we couldn't have to clutter up this thread, because I feel like I am missing something. I know you said to ignore the corners on D, but if we find an algorithm to swap the FR edge into the U layer, the D corners shouldn't get affected and would leave us with a standard EPLL. The only reason you have that "EP Parity" is because those corners on D are swapped.

My interpretation of what the cube will look like at the last step is if you do R U (ccw) R'. Notice how FR goes to UB, UB goes to UL, and UL goes to FR. Now if you do U' then R Uccw R' then you have a Ucw EPLL.

After typing that I just went and looked at Kirjava's example, and that's exactly what I thought it would look like. When you are at step 5 of his example do R' Ucw R. You are left with a Z perm.
 
Last edited:
My interpretation of what the cube will look like at the last step is if you do R U (ccw) R'. Notice how FR goes to UB, UB goes to UL, and UL goes to FR. Now if you do U' then R Uccw R' then you have a Ucw EPLL.
So you're saying that you wanted to do a 3-cycle. Okay. I don't get how you got to the nonsensical conclusion that each normal EPLL somehow only appears once, and that the solved case doesn't appear - I think it is pretty much blatantly obvious that adding a 3-cycle to the solved case gives you a *not* solved case, and that adding a 3-cycle to two EPLLs with different AUFs would give you two completely different cases. Do you honestly think that Uccw R Uccw R' and (y Uccw y') R Uccw R' would be the same case, or would be solved with the same algorithm? Try them both.

Look, if you want to do a 3-cycle first, you have to count every AUF of every EPLL. You can't go "THERE ARE 4 EPLLS SO THERE IS 4 OF EVERYTHING LOL". If you are dead set on doing it your way - and you shouldn't do it your way, because it leads to the confusion which you have expressed above - you have to count it like this: there are 4 ways you can have Uccw, 4 ways you can have Ucw, 2 ways you can have Z, one way you can have H, and one way you can have solved, for a total of 12.
 
I'll try EO now.
All edges oriented - 2 cases + solved
No edges oriented - 3 cases
2 edges oriented - 25 cases
4 edges oriented - 25 cases
total - 55 + solved

So for every case it's...
Code:
CO  CP  EO  EP
117 29  55  16  =  217
 
qqwref: I really enjoy the attack, honestly I do. I'm asking for help to understand something and instead of helping you are attempting to make me look stupid. Congratulations, go pat yourself on the back.

Yes, I understand adding a 3-cycle to solved case gives you an unsolved case. I also understand that 3-cycle AUF 3-cyle would end up with a different case. My point is that if you use R Uccw R' to insert the edge back into U, you'll be left with a standard EPLL case. For that reason, I don't understand how you can have EPLL parity.
 
Last edited:
I TRIED to help. I tried over many posts. I never wanted to waste several pages discussing why your approach doesn't work when there's no argument against mine. But at this point either you haven't been reading what I've said or you're unwilling/unable to understand it.

Swapping the FR edge and the edge in the FR slot (as in, doing a 2-cycle, as in, take out those two edges and put them back in each other's place) gives you a parity EPLL. You don't have to be able to get that by turning alone as long as you can imagine it, and it's worth imagining because it's mathematically useful in counting cases. And yes, you will end up with a standard EPLL case if you do a 3-cycle, I've already agreed with that, but (a) swapping two pieces doesn't mean doing a 3-cycle and (b) it still doesn't justify your incorrect case-counting approach.
 
This would probably be better off discussed outside of this thread. Would you care to take this to IRC or some other chat client? I know that you can't swap edge for edge directly, which is the exact reason why I said it doesn't matter what happens to the other edges in U when you swap FR for any given U layer edge.

The reason for me counting the way I did, is because I am trying to determine if using algs to swap FR to UF, UL, UB, and UR would take care of the "AUF" issue you addressed. This still does not excuse me missing the fact about Z and H though.
 
Last edited:
When someone has the balls to learn this, he'll decide to use whatever works for him and generate algs for it.

Since that person will have his own variation of the method anyway and will be doing his own research, I don't understand why this is still being discussed.

That was me in 2005, but at the time Roux was another promising method that no-one used that interested me more.

Interesting how no-one has considered generating the algs with the first layer on L yet :D
 
I'll try EO now.
All edges oriented - 2 cases + solved
No edges oriented - 3 cases
2 edges oriented - 25 cases
4 edges oriented - 25 cases
total - 55 + solved

So for every case it's...
Code:
CO  CP  EO  EP
117 29  55  16  =  217

when I count EO cases it goes like this

# of oriented edges - pattern desciption: # cases with Target edge on U + # cases with target edge in E
6 - all : 1 + 1 (excluding 1 solved case)
4 - 4 oriented in U : 1 + 2
4 - 3 oriented in U : 8 + 4 *
4 - oriented bar in U : 2 + 2 *
4 - oriented "L" in U : 4 + 2 *
2 - oriented bar in U : 2 + 2
2 - oriented "L" in U : 4 + 2
2 - 1 oriented in U : 8 + 4 *
2 - 2 in E : 1 + 2 *
0 : 1 + 2
___________________________________
28 + 22 = 55

-5 = 50 The 5 star cases denote cases wher ethe edge is already build - most likely no special alg necessary
-2 = 48 everything oriented is also easy

still alot I would start with edge 3cycles:
- if there are just two unoriented edges and one is in the target spot - an Edge 3-cycle will do it (things like r U' M U2 M' U' r' instead of M' U' M U2 M' U' M)

For cases with many unoriented edges it my be best to do some kind of iterator like Roux / LE5: do a quater turn on the face that contains the missing edges should be done in 13turns but Lookup is more complex than Roux. Also first placing the edge sometimes works.
 
Easier way to count EO stages:
- If the target edge is in U, AUF it to UF, and then there are 2^6/2 = 32 cases.
- If the target edge is in E, there are 4 ways it can go, and for each there is 1 way the top can have an even number of misoriented edges and 1 way it can have an odd number, so for each of the E edge positions there are 6 ((1+2+1) + (1+1)) orientation cases, for 4*6 = 24 cases.
So 32+24 = 55 + solved again.

I think the EO cases might end up really icky, maybe some CF tricks will come in handy but maybe there's not much we can do...
 
Now I'm intersted in EO CO CP EP.

EO: 128 + 192 = 319 + solved
U edges - 2^8/2 = 128
E edge - 4(4(1+1+4+2)+2(4+4)) = 192

If EO is right then there is no point of doing the rest.

EDIT: keep in mind that I wrote the first sentence before finding the # of cases.
 
Yeah, doing EO first is going to be a lot of algs. You could preorient like ZZ but that would make the first layer construction kinda ugly (and you'd have to make sure to include one E edge too, so you don't waste moves inserting that one later).
 
What about skipping the EO step altogether and using F/f RUR'U' F'/f' before doing CO/CP?

qqwref: I'm still not sure why I can't do the method I was talking about earlier. I'd really like to talk to you about that, but this thread clearly isn't the place for it anymore.
 
Last edited:
What about skipping the EO step altogether and using F/f RUR'U' F'/f' before doing CO/CP?
If you only orient the LL edges, what are you gonna do with edges that were on the E layer, and come up unoriented later?

qqwref: I'm still not sure why I can't do the method I was talking about earlier. I'd really like to talk to you about that, but this thread clearly isn't the place for it anymore.
Yeah, uh, I really don't care anymore. You can go on believing in a bad approach that gives the wrong number if you want to.
 
Back
Top