Athefre
Veteran
- Joined
- Jul 25, 2006
- Messages
- 1,335
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?
Edges first - speeding
- Thread starter mrCage
- Start date
Ah ok.
How many cases is it to orient all corners after the edges are solved?
mrCage
Veteran
- Joined
- Jun 17, 2006
- Messages
- 655
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
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
Veteran
- Joined
- Jul 25, 2006
- Messages
- 1,335
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
Veteran
- Joined
- Jun 17, 2006
- Messages
- 655
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
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
Veteran
- Joined
- Jul 25, 2006
- Messages
- 1,335
Oh, I know about commutators and mostly understand them. I just haven't used it enough to know the benefits.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...
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
Maybe you (YOU) can get a sub-20 edges first average?
What do you think?
mrCage
Veteran
- Joined
- Jun 17, 2006
- Messages
- 655
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
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
Veteran
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
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
Veteran
- Joined
- Jul 25, 2006
- Messages
- 1,335
"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.
: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.
