# Edges first - speeding



## mrCage (Sep 19, 2006)

Hi  

Im just curious if anyone here ever tried to speedsolve a 3x3x3 by doing edges first? Me and Gilles Roux did this the other day. For me it was the first time ever and i got an average of 35.97 secs on my first try. It's kinda cool to chase those fast corner cycles at the end of the solve. I'm sure some amazing times can be done with a bit of luck. So far my best time is 26.xy secs.

Have fun!

-Per


----------



## pjk (Sep 20, 2006)

What type of method is that? How exactly do you do the solve? I'd be interested in checking that out.


----------



## mrCage (Sep 20, 2006)

Hi B) 

The way i do i simply do the edges of first 2 layers intuitively. Edges on middle layers are easily inserted with 3-move algs like R U R' or whatever (cross down). Then i use also basic algs for the last 4 edges. Stuff like F U R U' R' F' is enough. For the centers i simply make up 8-move corners cycles on the fly, trying to solve 2 at a time if possible  

-Per


----------



## pjk (Sep 21, 2006)

Hmmm... that seems interesting. I really like the Fridrich method, and I can see why it is so quick. Roux also has a lot of potential.


----------



## Stefan (Sep 21, 2006)

> _Originally posted by PJK_@Sep 21 2006, 01:49 AM
> *Roux also has a lot of potential.*


Um... what? Isn't Roux more like edges *last* ? Kinda very strange you suggest that for edges first solving.


----------



## mrCage (Sep 21, 2006)

Hi!

I think he mentioned Fridrich and Roux as 2 interesting/fast methods in general. Not suggesting that those are edge-first methods  CFOP (Fridrich) is not edges first because not all edges are done first before doing the corners. Surely setting up the cross is solving 4 edges first, but then it deviates by making c/e pairs, so not doing corners last B) 

Cheers!

-Per

PS! Got my avg just below 30 secs for edges first. Not too bad ...


----------



## Johannes91 (Sep 21, 2006)

I have never tried this. I always thought it's a bad idea.  Sub-30 is really good... :blink:


----------



## Stefan (Sep 21, 2006)

> _Originally posted by Johannes91_@Sep 21 2006, 01:22 PM
> *I always thought it's a bad idea.
> *


What?? Why?? They even used this strategy to improve the upper bound for QTM last year:
http://cubezzz.homelinux.org/drupal/?q=node/view/34


----------



## Johannes91 (Sep 21, 2006)

> _Originally posted by StefanPochmann+Sep 21 2006, 02:50 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>*QUOTE* (StefanPochmann @ Sep 21 2006, 02:50 PM)</td></tr><tr><td id='QUOTE'>
> 
> 
> 
> ...


_
Because I don't think it's a very good idea.

<!--QuoteBegin-StefanPochmann_@Sep 21 2006, 02:50 PM
*They even used this strategy to improve the upper bound for QTM last year:
http://cubezzz.homelinux.org/drupal/?q=node/view/34*[/quote]
So what? We are talking about speedsolving here.


----------



## Stefan (Sep 21, 2006)

I got a few times slightly above a minute. Then I cheated and got 43.28 seconds.


----------



## Johannes91 (Sep 21, 2006)

I tried two times, 34.xx and 31.xx. It's not that hard, actually. I'll do an average now...


----------



## chiperten (Sep 21, 2006)

When I first learned to solve the cube I thought I was cool by inventing my own "method." Ofcourse I used all the same algs as the standard layer-by-layer method I had learned. I solved all the edges, then did 3 corner cycles to first get all of two opposing sides to have the right corners. Then moved the corners around, again using 3 cycles, to place the corners. And finally, I'd orient all the corners using the (R U R' U') commutator any multiple of 6 times. Obviously this wasn't very fast for me.


----------



## Kirjava (Sep 21, 2006)

I'm interested to see how many moves you're taking to make the edges first. I thinking roux would be much faster for this? Especially the way the last six edges are done? I could see doing the edges in maybe 6 seconds with practise.

Just did five solves move-wise. Standard speed-solve, no FMC.
26 - 23 - 20 - 26 - 26

The 26's were the ones with parity. None were lucky...


----------



## chiperten (Sep 22, 2006)

I do 3-cycles to permutate the corners... but what are you doing for orientation?


----------



## Johannes91 (Sep 22, 2006)

I solve the corners directly to their places with commutators (3-cycles), so I don't need to do orientation separately.

Roux might be a good idea. Starting with cross doesn't really make sense to me, because it's just on the way when solving other pieces (and this is one of the reasons I hate Fridrich). 1x2x3-blocks leave M and U free, I really like that idea.

Another method for edges:
Step 1: Orient all edges and solve DF and DB.
Step 2: Solve F2L [R,U,L,D2]
Step 3: Permute LL

I did a few solves (edges only) and they were around 20-30 moves, even though I'm not used to this at all. I'm going to practise this today. My PB is now 25.88 B)


----------



## chiperten (Sep 23, 2006)

I just read Doug's tutorial on conjugates and commutators again.. and I'm amazed. This time I actually understood completely what was going on. It is fun making up these commutators to solve any thing that's thrown at you when it comes to corners only.


----------



## mrCage (Sep 29, 2006)

Come on guys B) 

My just-sub 30 average was for solving edges AND corners, edges first before im allowed to think of corners. Except simple tricks to preserve already solved corners of course. I have not tried a move-count for complete solves with this style yet  

-Per


----------



## Athefre (Oct 1, 2006)

People are saying their solves take 20-30 moves in a normal speedsolve. Is that just the edges? Because if it's not then everyone should start doing FMC...


----------



## Johannes91 (Oct 1, 2006)

> _Originally posted by Athefre_@Oct 1 2006, 03:37 AM
> * People are saying their solves take 20-30 moves in a normal speedsolve. Is that just the edges? Because if it's not then everyone should start doing FMC... *


 Those movecounts were just for edges. For edges and corners it takes me around 45-65.


----------



## Johannes91 (Oct 1, 2006)

> _Originally posted by mrCage_@Sep 29 2006, 06:33 PM
> * Come on guys B)
> 
> My just-sub 30 average was for solving edges AND corners, edges first before im allowed to think of corners. Except simple tricks to preserve already solved corners of course. *


 I think that's pretty obvious . For edges and corners, my best average is sub-35 and best single solve 24.xx.


----------



## Athefre (Oct 2, 2006)

> _Originally posted by Johannes91+Oct 1 2006, 09:20 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>*QUOTE* (Johannes91 @ Oct 1 2006, 09:20 AM)</td></tr><tr><td id='QUOTE'> <!--QuoteBegin-Athefre_@Oct 1 2006, 03:37 AM
> * People are saying their solves take 20-30 moves in a normal speedsolve. Is that just the edges? Because if it's not then everyone should start doing FMC... *


Those movecounts were just for edges. For edges and corners it takes me around 45-65. [/b][/quote]
Ah ok.

How many cases is it to orient all corners after the edges are solved?


----------



## mrCage (Oct 6, 2006)

Hi :huh: 

Why would u want to do that? That would be a real bad strategy i guess. Better strategy is to make up 3-cycles that solve (hopefully) 2 corners in one alg. If that's not possible solve at least one corner correctly by a 3-cycle, while bringing *bad* corners into play: for instance a corner that just needs twisting. Yes, making up commutators is the key then. Experience helps <_< 

Have fun!

-Per


----------



## Athefre (Oct 7, 2006)

> _Originally posted by mrCage_@Oct 6 2006, 08:44 PM
> * Hi :huh:
> 
> Why would u want to do that? That would be a real bad strategy i guess. Better strategy is to make up 3-cycles that solve (hopefully) 2 corners in one alg. If that's not possible solve at least one corner correctly by a 3-cycle, while bringing *bad* corners into play: for instance a corner that just needs twisting. Yes, making up commutators is the key then. Experience helps <_<
> ...


 I just thought it might be easier and it might be less moves. I know that less moves doesn't really mean faster times so please don't tell me that.

Why would someone want to guess the whole time they are solving and hope that they are solving corners?

I guess I shouldn't be saying stuff since I don't know much about it.


----------



## mrCage (Oct 7, 2006)

Hi 

It's not about guessing that u solve (correct orientation) a corner as u move it from A to B. It's about seeing that it will be like that...

Take an easy corner 3-cycle : 

R' D R U R' D' R U'

This breaks down into 4 steps:

- R' D R moves a corner from D layer into U layer (correctly oriented)
- U moves that solved corner away
- R' D' r is the inverse of first step, puts back the corner that was moved away from U, but back into a new location
- U' simply undoes U from step 2

Many corner 3-cycles are constructed this way. The whole construction is a commutator PQP'Q' with Q being turning a single outer layer. For making similar 3-cycles with edges Q may be an inner (slice) or outer layer.

Orienting corners first would lead to that u need more algorithms in total (in general) to solve them. For 2x2x2 however ur idea works very well. Because there are no edges to be disturbed by short known permutation algorithms 

Cheers!

-Per


----------



## Athefre (Oct 8, 2006)

> _Originally posted by mrCage_@Oct 7 2006, 08:50 PM
> * Hi
> 
> It's not about guessing that u solve (correct orientation) a corner as u move it from A to B. It's about seeing that it will be like that...
> ...


 Oh, I know about commutators and mostly understand them. I just haven't used it enough to know the benefits.

Maybe you (YOU) can get a sub-20 edges first average?

What do you think?


----------



## mrCage (Oct 9, 2006)

Ummm ... :unsure: 

Well, i still didn't hit under 20 with a single time. So doing average sub 20 will be VERY hard ... I've only ever sub'ed 20 with my normal speeding method once  

I will try some more when i get the time. Next target >> sub 28 average  

-Per


----------



## cuBerBruce (Oct 9, 2006)

Athefre asked about how many corner orientation cases there would be.

Obviously, there are 2187 corner orientation cases. Of course, this can reduced to a much smaller set of "cases." Symmetry and setup moves can be used to greatly reduce the number of cases that someone needs to consider. The actual number of cases depends upon the symmetry group you use and what you are willing to use as setup moves. The simplest setup move case would be to allow U layer rotations to align the top and bottom layers differently.

Well, I wrote a little program to try to count the orientation cases. This is what I came up with. Numbers in parenthesis indicate the number of cases if you don't count mirrors as separate cases.

Using four cube orientations preserving U facing up, followed by an optional U setup move: 192 (114)

Using eight cube orientations leaving U facing up or down, followed by an optional U setup move: 100 (65)

Using all 24 cube orientations, but no setup move: 111 (66)

The above numbers include the all corners oriented position, so subtract one from each number if you don't consider that position to be a "case." Note that when cube orientations are used that move the U face to a side face, the orientation cases will look different.

I will also enumerate the different combinations of the numbers of corners with each twist state. It would seem that if you had an alg for one instance of each of these cases, you could use setup moves to convert any corner orientation case into the case for one of those algs. This would only require 14 algs, of which I believe 5 could be mirrors of other algs. This may require learning lots of "setup cases," though. I'll use triples giving the number of oriented cubies, clockwise-twisted cubies, and counter-clockwise-twisted cubies. These cases are:

(8,0,0), (6,1,1), (5,3,0), (5,0,3),
(4,2,2), (3,4,1), (3,1,4), (2,6,0),
(2,3,3), (2,0,6), (1,5,2), (1,2,5),
(0,7,1), (0,4,4), (0,1,7)

Anyway, I think it should be possible to orient all corners using a reasonable number of algs. One could also do corner orientation in two steps instead of one step. As Per said, you could also orient the corners as you move them to their proper locations, perhaps by using 3-cycles.

- Bruce


----------



## Athefre (Oct 10, 2006)

"Obviously, there are 2187 corner orientation cases."

:unsure:

So about 100 cases if you don't mind adjusting U and D?

I'm not going to learn it, it's just nice to know. Someone else might want to try it.


----------

