# New idea (I think) for big cube BLD



## blah (Jun 28, 2008)

I had this idea last night while _trying_ to sleep (been rolling all over my bed for more than an hour but had this inexplicable one-night-insomnia thing for no reason whatsoever ). Disclaimer: I _think_ it's a new idea because it just came from my head and I've never read about it anywhere else before, though to be honest, I haven't really read much literature on big cube BLD, yet. So yeah.

I think it can be very, very, very useful for odd cubes (5x5x5 and 7x7x7). In fact, the bigger the cube, the more useful this is, I _think_, it's just pure intuition without mathematical backing (I'll prove/disprove this later once I _know_ nobody's done this before, so I don't waste my time ).

The idea: Maximizing solved centers for odd cubes. How? Do exactly the same as you would for a 4x4x4: Look for the side with most number of solved centers, _ignoring the 'center center'_. Then solve the whole thing normally like you would on any even cube, and finally, the three most important algorithms that are so intuitive I don't think they deserve to be called algorithms:

(r l') (u' d) (f b') (r l'), its inverse, and u m2 e' m2 d'.

I dunno if I'm using conventional notation and I'm too lazy to figure out the conventional notation for these algs, so this is what I mean: Lower case udfbrl mean the slice AND all layers 'outside' it, lower case m and e mean ONLY the central slice. Okay I know there's definitely a better fingertrickish way to do them but I'll wait for somebody to discover that and tell me 

If this isn't a new idea and is what everyone else is doing now, tell me, link me to a thread (or page for that matter), and I'll delete this.

Edit: Wait, I just discovered I'm not _author_ized to delete this thread though I'm the _author_, irony?


----------



## cmhardw (Jun 28, 2008)

Stefan Pochmann posted about something like this for 3x3x3 BLD about 2 years ago now, I think it was. I think it's a good idea, the only thing that makes it harder, which Stefan pointed out, is that because you are now viewing the centers as permutable pieces you now have to watch out for _center parity_. If the centers are in an odd permutation, then the parity of the corners and centralmost edges will not match. You would either need to know to count the center permutation cycles to see if it's even or odd before memorizing, or learn special parity algs to fix this.

To be honest, I don't know why anybody, including myself, really uses this for 5x5x5 BLD. I agree that it would definitely speed up the solve in some cases, though for 5x5x5 I think the time spent counting the center cycles, though small, will not always balance the time gained by maximing solved x-centers and t-centers. Like you said about bigger cubes, with the new 7x7x7 coming out, I think a strategy like this would basically be *required* in order to ensure a fast time (for those trying for fast times on 7x7x7 BLD).

Chris


----------



## masterofthebass (Jun 28, 2008)

I haven't heard of this either. The only problem, is that you still have to pick the right orientations. So lets say you solve with white on top and green on front. if you picked the orange side to be your green, then you would have to make sure your new white face would have to be on either the white or blue centers. If you picked the yellow center, there would be no way to solve them , as you would end up with corner parity. Interesting idea, but I really don't think solving the 5 more centers will be that hard.


----------



## joey (Jun 28, 2008)

I told Alex Yu about this, and he got a fast 3x3 BLD with M' E2 M E2. I think it's good, but hard to see without spending too much time.


----------



## blah (Jun 28, 2008)

@Chris: I have no idea what you're talking about when you say stuff like 'corner parities with centers' or something like that, sorry. 'Cause I've only attempted one 5x5x5 BLD in my life and was successful on that attempt, and I've never read anything on 5x5x5 BLD yet, I'll try playing around with it sighted and see what happens. Edit: Can you explain what you mean by 'permutable pieces'? I find that very trivial, aren't all pieces permutable? Or do you mean center centers? (Is there a better name for them?)

@Dan: Umm, I'll try asking Per, he might know some algorithm that swaps two adjacent 'whole' centers. It's probably something you need to know for cage? I think.

Can't you solve corner parity with the edges and leave the centers 'independent'? I don't know of any but there's gotta be some algorithm out there that swaps two corners and two midges right? (something like a PLL, only it affects midges instead of tredges, or 5-dges for 7x7x7.) I _really_ have no clue what you're talking about, Chris, so I'm making a random guess. If this suggestion doesn't make sense to you, forget it 

@Dan, again: I can't believe this. 2 minutes ago I was replying you (something about consulting Per), and now I've found a solution to the problem you mentioned  First solve any center with any of the 3 algorithms (then the opposite one has to be automatically solved), you now have four center unsolved, do a PLL parity alg (which takes at most 3 seconds), and you'll get a final stage Roux. I don't know how to solve this but there's gotta be some Roux guy out there who has the optimal solution to this, or ask Gilles himself?

Second edit: Okay now everything's falling into place. Let me try to get this straight now that I've processed the information everyone's given me, tell me if I got it all wrong: 

1. Chris' permutable pieces refer to center centers. Can we just call them that from now on?
2. Center parity means that since now the center centers are cyclable (= permutable, actually I never saw it that way, I saw it as large chunks of the cube moving around the little centers  new perspective), the cube might get into a state of...
3. The example Dan mentioned. And I've found a solution to that with the final Roux thing that I haven't figured out, but I ran a few tests on Cube explorer and no matter which two tredges I swap, the optimal solution is always 14 turns, though I haven't even gone through the solutions it gave me yet, later.
4. Now I'll compare the Roux solution and Per's solution (if any) and see which is faster then I'll stick to that, if I ever get to doing 5x5x5 BLD seriously.

Third edit: Something's wrong. I came up with the Roux solution by toying around with my 4x4x4 (I hate my 5x5x5, it's not the smoothest thing in the world), I forgot that there wasn't any PLL parity on a 5x5x5. So now I'm back to having no solution.


----------



## masterofthebass (Jun 28, 2008)

blah...

you can end up with parity if your centers are out of whack. This means you will have 2 corners swapped, along with 2 centers. Try ignoring centers on a 3x3 and do a fridrich solve. You'll see what I mean 50% of the time.


----------



## blah (Jun 28, 2008)

Yeah that's exactly what I tried, but I fixed the corners to get 2 edges swapped instead and ended up with my Roux case.


----------



## cmhardw (Jun 28, 2008)

Hey blah,

Actually I think part of the confusion is that I mis-interpretted what you were talking about for fixing the centers, I understand now. So you mean that if on the red face I have lots of blue centers, and on the blue face I have lots of red centers then I will solve the blue centers to the red face, and the red centers to the blue face, then at the end of the solve I will apply an algorithm to switch the group of blue and red centers onto their correct faces.

I was talking about seeing a large group of blue centers on some random face, and on some adjacent face to that seeing a lot of yellow centers. I would then rotate the cube such that the group of blue centers is on the back face, and the group of yellow centers is on the U face (which is where blue and yellow are for my color scheme). Then at the end of the solve I would do an algorithm like E' M E M' or S E S' E' to move the center centers to their correct locations.

Permutable pieces was another way of saying the centers are now seen as pieces that can move, and not as immobile reference points.

I think either way would be a good idea of how to make the solve easier, especially for big cubes BLD (6x6x6 and 7x7x7).

Chris


----------



## blah (Jun 28, 2008)

Double posting 'cause I've got another thought.

I don't see why my Roux solution won't work. All we have to do is simulate a PLL parity on a 5x5x5, which is swapping Fu and Bu T-centers, easily done by commutators, and swapping FU and BU midges, which I don't yet know how to do. Anyone? Then we continue with the Roux solution.

Edit: @Chris, dude your first interpretation of what I was saying was correct. Your second interpretation was the thought from which this idea of mine developed


----------



## deadalnix (Jun 28, 2008)

when you move a M slice, you move 4 center-center and 4 edges, so you'll have a parity center-center / edges. As you have a parity edges/corner, you can get a parity center/corner too.

A good introduction to the problem is advanced roux method.


----------



## masterofthebass (Jun 28, 2008)

Blah.... I see what you mean now. I was thinking what chris' 2nd though was. Now I understand what you mean. It could work out somewhat well though.


----------



## blah (Jun 28, 2008)

If two people had two different interpretations then there's something wrong. I should go edit my first post to make it clearer for future readers, but that problem you mentioned still exists though. And I still haven't found a solution to it 

Edit: Wait, it doesn't exist, of course it doesn't exist, because you CAN'T swap two midges in the first place right? And I was cracking my head for a solution... So now I've got a new problem, what was Chris talking about when he mentioned center parity? Guess I'll have to figure that out all over again.

Second edit: Okay I've finally got everything figured out, everything. Here goes:

The parity that Chris mentioned was this, take your 3x3x3 cube and do this: U2 R' U' B L F' U L2 R D' L D F' R' z y, there's a (z y) rotation at the end because I rotated the cube wrongly when I colored the cube in Cube Explorer. There's actually two more cases with different edges swapped, but they're all transformable to one another using edge-cycling PLLs, so just see them as one case. This is obviously a Roux final stage and the optimal solution to this can be found by asking any Roux user (I quit learning Roux because this was the only part I didn't have the patience to understand ) or by using Cube Explorer, which gave me a 14 move solution that sucks for fingers, memorizing the algorithm itself, and accuracy during BLD, yeah all three. So I still need an optimal solution from a Roux user. And this is why 50% of the time, got this figure from Dan, not all your midges will be solvable if you're using this centers-maximizing approach that I proposed.

Chris, is this the parity you're talking about? There's no corner problem because I fixed them and permuted the edges instead.

Third edit: Read Chris' post again, quite sure this is what he's talking about. And my universal solution to this problem is, don't bother counting the center permutation odd/even-ness, probably too time consuming imo, which means you're not restricted by that example Dan mentioned. If there's even permutation, everything's memorized normally, good; if there's odd permutation, you'd know because your midges permutation won't add up with corner permutation, so you'd either have a) 2 corners swapped, all edges solved, or b) 2 edges swapped, all corners solved. Case a: someone got a T perm that swaps 2 corners and 2 midges? Then it'll become case b, if there's no such algorithm, I dunno a fast way to do it  (the slow way would of course be to do a T perm with the tredges and swapping the wedges back). Case b: do the Roux solution that someone's, hopefully, gonna provide soon.

Fourth edit: ACube returned me a retarded 17 move MU 2-gen solution, and everyone knows how fun it is to do M moves on big cubes. So I guess Cube Explorer's solution is the best by far. Now all I need is an algorithm that swaps two corners and two midges, anyone?

Fifth edit: Can't believe how stupid I was, it was on bigcubes.com all along (well I didn't know because I don't speedsolve the 5x5x5, the biggest cube I speedsolve is the 4x4x4). So the solution to case (a) is: T-perm then (Uu)2 (Rr)2 F2 u2 F2 (Rr)2 (Uu)2. I don't think this is very fast, but it's not disgustingly slow either, so I'm fine with it.


----------



## Stefan (Jun 28, 2008)

The earlier thread that Chris mentioned:
http://games.groups.yahoo.com/group/blindfoldsolving-rubiks-cube/message/506

I think I only had the 3x3 in mind back then, though.


----------



## blah (Jun 29, 2008)

Thanks, Stefan. Read through all the posts, but how come that thread got neglected after only _one day_? Seems Chris was pretty happy about it back then, but apparently he's not using this now based on his posts in this thread. Why, Chris?

Stefan, instead of restricting yourself to only 11 other center orientations (which you have to waste time thinking and counting to know which orientations are "possible" and which are not), I think it's a good trade-off to use any of the 24 center orientations you like and fix the 12 "wrong" ones with the Roux thingy I mentioned above. A 14 move Cube Explorer solution can probably be reduced to less than 10 moves in STM, I'll try ACube later.

Now, all these center-permuting algorithms will probably average ~11 moves or so after considering probability and other stuff (I don't really know what else there is to consider) in your calculations, correct me if someone's found the exact number and I'm way off it  So you're spending, say, 6 seconds to rotate your cube to maximize solved centers/corner orientations/whatever you hate solving, and another 6 seconds to think which direction you should cycle your centers. Plus another 3 seconds for executing the algorithm, that's 15 seconds. Compare that to solving 5 more center pieces (I think this is a very reasonable number for 5x5x5, probably much more for 7x7x7), or orienting 5 more corners, there's no way all those commutators or CO algs can take less than 15 seconds even if they're so mechanical you don't have to think at all.

I can see this idea being less useful for the 3x3x3 because there are more and more guys getting sub-minute times already. But for big cubes, I really don't see how this can slow anyone down.

P/S: I feel smart for coming up with a Pochmann idea independently 

Edit: I've added a five whole chunks of edits to the posts two posts above this, please check them out and comment, thanks.


----------



## deadalnix (Jun 30, 2008)

A vocab point :

center-center isn't realy clear. In french, we call "centres point" (point centers) which is better (I think).

I think about the question and here a way to find a center permutation with no parity easily. You only need to limit yourself to half turn rotation (x2,y2,z2) and corner rotations (xyx,xy'x). Corners rotation is realy easy to fingure with a real cube but hard to explain with standard notations


----------



## blah (Jun 30, 2008)

I thought that trick you suggested to determine "center paritiness" was trivial? Since that's what both algs do: one swaps two sets of opposite centers, and the other cycles three adjacent centers about a fixed corner (if you wanna see it that way, that's how you described it anyway).

And I mentioned up there that it's in my opinion much better to ignore this annoying center parity thing and fix it in the end with Roux. Then you'll have more freedom to _really_ maximize solved centers and still be able to fix it in the end by just learning an additional alg or two.

I don't know about you, but I've got a feeling I'll be pretty damn p***ed off if I find a _really_ nice center orientation with like 20 or more solved centers (both x- and t-, I don't think that's unlikely at all) just to find out that I can't use that orientation. So yeah I'm quite sure I'll learn that Roux alg by heart if I ever start seriously blindsolving a 5x5x5 or for that matter a 7x7x7.


----------



## deadalnix (Jun 30, 2008)

In a roux style, you'll mix the t-centers.


----------

