Developing alternative 4x4x4 method (Move count: ~110 without parity)

blah

brah
Joined
Dec 30, 2007
Messages
2,139
Location
.
Title says it.

I won't reveal it yet because it's still very crude and there are lots of cases to which I haven't found nice solutions, but I just wanted to know if I should continue developing it. So I want to know what's the average move count for a normal 4x4x4 solve by the fast guys (Erik, masterofthebass, etc.?). Can you guys do a couple of typical solves and give me an idea of your move counts?

I think 110 (without parity) is a little too high but I'm working on completely eliminating parity, which might bring this figure up to about 120, I'm not even sure if eliminating parity is possible at all but it's worth a shot, I think. Thanks.

Edit: Anyone can post their move counts actually, the more people the better, or link me to another thread that has already discussed this? Couldn't find one using the search function.

Edit 2: Slice moves count as 1 move, just in case you wanted to know.
 
Last edited:
centers: 23
edges: 41
3x3: 68 lol, 16 move OLL, 17 move Yperm

centers: 26
edges: 49
3x3: 63, whats with all the 2-look OLLs?

centers: 23
edges: 42+parity= 54
3x3: 58, still a 10 move OLL and v-perm

centers: 24
edges: 43
3x3: 61

centers: 33 bad
edges: 43+parity=55
3x3: 51 easy

totals:
centers: 23, 26, 23, 24, 33 --> 25.8
edges(counting parity): 41, 49, 54, 43, 55 --> 46.4
edges(not counting parity): 41, 49, 42, 43, 43 --> 43.6
3x3(no parity): 60.2

total= 129.6/132.4

so this is decent, I am not especially efficient, but I think i do an ok job. edge pairing parity is usually right around 4-5 sec for me so its not really that bad.
 
I think 110 is a bit low; it takes me a bit of care to get near 100 for non-parity FMC.
20 centers is not easy in a speedsolve, 50 3x3x3 with no inspection is hard, and edges take more than 25 moves, definitely. That's not even counting parity, mistakes and inefficiencies.
 
hello :)
Is this a direct solving method? mm.

I just did a move count, 126. for my CF, centres last method. yea. my average should be around 135 to 145? centres last is NOT move efficient.

but anyway good luck with your method, haha.
 
centers: 33
edges: 50
3x3: 56 + both Parities 22
= 161

centers: 27
edges: 42
3x3: 62+ OLL-parity 15
= 146

centers: 27
edges: 40
3x3: 62 + PLL-parity 7
= 136

centers: 28
edges: 44
3x3:67+ PLL-parity 7
= 146

centers:26
edges: 44
3x3: 53 + both parities 22
= 145
 
I don't understand why you don't post your (partial) method yet? That would allow us to help you developing it.

Also, avoiding parity with a reduction method (actually, with a centers first method) will only be a good idea if it:
a) Doesn't increase the solving time for solves that didn't have parity (single)
or b) is faster than 50% of the time it takes to perform the parity-fix (average)
 
Wow, it's really tempting to do a 4x4x4 fewest moves attempt on gelatinbrain and get really high on that list. Given 2 1/2 hours to work on it, I almost always come in under 100. :)

(Although I've not tried it where slice moves count 1 instead of wide moves.)

blah, I'm really looking forward to seeing your new method.
 
Sorry for the late reply guys :p I just did a few more trials yesterday, and turns out my first 5 runs (which gave me an average of 110 moves) were all extremely lucky for some unknown reason. Now I'm about 130 to 140 on average :p So I guess I should just give up, it's a pretty stupid method anyway :s
 
Last edited:
Wow, it's really tempting to do a 4x4x4 fewest moves attempt on gelatinbrain and get really high on that list.
Yeah, I just realized that I've been doing all my computer 4x4x4 FMC solves on the Heise sim. So I tried the gelatinbrain:
First attempt: 92 [PLL parity] :p

Lucas, for 4x4 fewest moves why not count cycles? That's what I do. Count cycles in the 24 edges to determine the initial parity, and if you use reduction then make sure you solve the centers such as to reduce the edges parity to even. Then when reducing the wings to be wing-groups make sure that you solve the last groups such as to create the same parity as what the corners would become (to avoid any parity at all). For 4x4x4 fewest moves you should never have any parity :rolleyes:
 
If anyone still wants to know about it you can PM me, but it's pretty pointless, really :s

By the way, it's just a modification/combination of many different methods out there, nothing's original at all :p
 
But I'm not :p I just think I made a stupid mistake by starting this thread before sufficiently testing the "method" and now I regret starting this in the first place :p But I'll tell anyway, briefly.

1. Two opposite centers. My move count shot up at this step, because for normal reduction solves, I'm color neutral at this step, but for this "method", I have to solve white and yellow, you'll find out why later.

2. Solve 3 cross dedges, one of them in the wrong order, this becomes surprisingly easy to do after a while, because you have more freedom. If you don't understand what I just said, I'll give an example: say you have white center on D, then you'd solve, for example, red-white on F, green-white on R, and orange-white on L. Notice that red and green are in the correct order, but orange is intentionally placed at the wrong position, that's what I meant by one of them in the wrong order. Of course, any other combination will work. Use whatever method you want to solve them, direct solving, or pairing then solving, I haven't found the most efficient method yet.

Yeah, I got the idea for the first 2 steps from K4, though I don't know what the original K4 is like, never seen it (I just know some variations from YouTube and other websites).

3. Like K4, solve the other centers with the working area you have where there's no cross dedge. This is the step that kills me in terms of move count and lookahead.

4. Solve the last cross dedge. How I do it: Place both edges in the E (u and d) slice such that you can pair them up with a Uw/Uw'/Uw2 move. In my above example, the last remaining dedge would be blue-white, so form the blue-white dedge, turn D such that it's above orange-white, solve blue-white, ADF, solve orange white, turn Uw back. (Have a cube with you while reading this to understand what I'm talking about.) And this is why you placed orange-white in the wrong position earlier.

5. Now you got a cross on bottom, here's the step that can be crazy fast with practice, and if I resolve some of the really awkward and annoying cases, I think. Use Yu Nakajima's edge pairing method to solve all dedges. You can also use 2-pair. I still haven't decided which is better :p

6a. Here's where all the messed up parts kick in. For the last 3 or 4 dedges, I use 2-pairing because I don't know how else to pair them up. But then with 2-pairing, I'd occasionally mess up my cross (I think I know why but I haven't really investigated yet). So, to stop messing up my cross, I do loads of R [ U ] R' to setup the dedges for 2-pairing, and this is where I'm really inefficient as well. Anyone got a better idea?

6b. If you've got 2 dedges left, do this (instead of the normal algorithm): Dw RU'R' F'U'2F Uw'. It's quite intuitive. I don't know if there are more efficient ones, I just found this on my own. If they're opposite (one at FR, the other at BL), you get a nicer alg: Uw2 RU'R' F'U'2F Uw2.

7. Solve everything else like a 3x3x3, duh.

(8). I've been thinking of leaving 2 or 3 edges unpaired towards the end, and solving them using commutators in the end, to avoid parities altogether, but haven't really given it much thought or work though, anyone got any ideas? Edit: Actually, I think this is quite impossible now, because if parity could be avoided this way, people would've done it long ago with other reduction methods, and since they haven't, I think it's not possible. (I know that's very flawed logic, but whatever :p)

Now, for the "why?"

I had a huge problem with solving cross right after reduction, I just couldn't spot my cross edges quick enough and I'd take something like 10 moves to get it done, so I wanted a method that could bring me straight into F2L after reduction.

I also liked "the second part" of Yu Nakajima's edge pairing method (the part after the cube rotation), because you don't have to look at D at all, and you don't even have to turn D, so you get very fast lookahead and very high turning speed during edge pairing.

With these 2 factors, it was only natural for me to come up with something that gave me (a) all centers solved, (b) 4 cross dedges solved, (c) cross formed on D, hence this method.

I've tried 2-pairing and 4-pairing to solve cross dedges and place them on D before proceeding to pair the remaining edges, but I just didn't like it because it was way too inefficient for me.

Then I stumbled upon K4, modified it a bit, and came up with this. That's it. I've got a pretty weird definition of "brief".
 
Last edited:
Wow, it's really tempting to do a 4x4x4 fewest moves attempt on gelatinbrain and get really high on that list.
Yeah, I just realized that I've been doing all my computer 4x4x4 FMC solves on the Heise sim. So I tried the gelatinbrain:
First attempt: 92 [PLL parity] :p

Lucas, for 4x4 fewest moves why not count cycles? That's what I do. Count cycles in the 24 edges to determine the initial parity, and if you use reduction then make sure you solve the centers such as to reduce the edges parity to even. Then when reducing the wings to be wing-groups make sure that you solve the last groups such as to create the same parity as what the corners would become (to avoid any parity at all). For 4x4x4 fewest moves you should never have any parity :rolleyes:

Chris, I've been trying this for a while, and I think I understand what you're saying, but it's not necessarily easy to actually do this. For OLL parity, I actually found it was easier to just come up with a solve for the centers, then quickly solve it to see if I get OLL parity, and if I do, then just change the centers solve so if the number of center slice moves was odd, it becomes even, or vice versa. So anyway, I'm doing the same thing as you, but without thinking as hard. :)

But for PLL parity, I can see if there is parity, but a lot of times I can't find a way to fix that parity without increasing the moves as much as solving parity would take. (Especially when you consider that you can almost always insert the parity fix somewhere in the edges solve and reduce it to just 7 moves). So when you say "make sure that you solve the last groups such as to create the same parity as what the corners would become", I'm saying that seems straightforward in theory, but in practice I don't know how to do it effectively. I was trying to always remove all parity, but lately I've just been settling for reasonable edges with or without PLL parity.
 
Thanks for posting blah, but I don't really see a way that saves moves or speeds up the proces. I think you should just practise transitioning from pairing to cross more.
(Also, I don't understand why step 1 requires starting on white or yellow. Unless that is because you have to form the white-cross.

Chris and Mike: It isn't even necessary to count cycles. Lars and I discussed this while driving back from Nantes Open 2008 and counting individual edge orientations was good enough. However, during the center-stage you have to pay attention with every move how many pieces change orientation. We concluded that it would work to predict OLL-Parity during inspection, but that it wasn't possible to keep track of the orientation-changes during centers (on a speedsolve). For FMC it should be doable though and fixing the OLL-Parity should happen during the 3rd center (most freedom)
 
Last edited:
I didn't say it saves moves or speeds up the process ;) I just said I hated the transition so I was testing a new method that, well, failed me :p Guess I'm just gonna have to go back to normal reduction :( I'm not color neutral, that's why step 1 has to start on white or yellow, but that's just me :p
 
Back
Top