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.

I was wondering, is there anyway I can avoid getting the parity errors on the 4x4x4 cube? I'm not too keen on memorizing the extremely long algorithm's =)

I was wondering, is there anyway I can avoid getting the parity errors on the 4x4x4 cube? I'm not too keen on memorizing the extremely long algorithm's =)

Actually...I thought about how to avoid parity issues on the 4x4 and I realized that although there really is only permutation parity, with redux it seems like 2 different parities.

I dealt with the orientation parity by using ZZ. by pairing the edges and placing them oriented on the sides (using M freeslice) you could guarentee that those edges were oriented. After solving the EOline there are only 4 edges left to pair, which can be done in 2-3 algs.

Then I had to worry about the "PLL parity". I found that if the blocks were solved ZZ style and the corners done with COLL, the LL edges can be solved with parity, with only 5 more algs (1 being the standard PLL parity alg).

This results in a 2LLL all of the time, compared to the possible 4LLL with Fridrich Redux, and has a significantly lower movecount (20 if I remember correctly) which is shorter than the OLL parity algorithm.

But, because I have left ZZ for Roux, ZZ blockbuilding and COLL won't be used by me again, so I abandoned this idea, very well knowing that it could be extremely fast, faster than K4 even (don't say I didn't warn you Kir).

I was wondering, is there anyway I can avoid getting the parity errors on the 4x4x4 cube? I'm not too keen on memorizing the extremely long algorithm's =)

Actually...I thought about how to avoid parity issues on the 4x4 and I realized that although there really is only permutation parity, with redux it seems like 2 different parities.

I dealt with the orientation parity by using ZZ. by pairing the edges and placing them oriented on the sides (using M freeslice) you could guarentee that those edges were oriented. After solving the EOline there are only 4 edges left to pair, which can be done in 2-3 algs.

Then I had to worry about the "PLL parity". I found that if the blocks were solved ZZ style and the corners done with COLL, the LL edges can be solved with parity, with only 5 more algs (1 being the standard PLL parity alg).

This results in a 2LLL all of the time, compared to the possible 4LLL with Fridrich Redux, and has a significantly lower movecount (20 if I remember correctly) which is shorter than the OLL parity algorithm.

But, because I have left ZZ for Roux, ZZ blockbuilding and COLL won't be used by me again, so I abandoned this idea, very well knowing that it could be extremely fast, faster than K4 even (don't say I didn't warn you Kir).

you are basically 100% wrong. First off, there's still the standard OLL and PLL parity in the K4 method. Second, even if you use ZZ, you still encounter both types of parity during solving. Odd edge parity can happen no matter what method you use, you just happen to notice it earlier when using ZZ. As for using more algorithms to solve PLL, that can be done with standard reduction as well, if you use COLL. The problem is that there aren't any decent algs for O/W perms, which makes doing it in one look almost worthless.

you are basically 100% wrong. First off, there's still the standard OLL and PLL parity in the K4 method. Second, even if you use ZZ, you still encounter both types of parity during solving. Odd edge parity can happen no matter what method you use, you just happen to notice it earlier when using ZZ. As for using more algorithms to solve PLL, that can be done with standard reduction as well, if you use COLL. The problem is that there aren't any decent algs for O/W perms, which makes doing it in one look almost worthless.

Basically, yea I am. I know about the odd pairing, and I know about the LL part too. I had 12 (I think) turn O Perms. I understand what you're saying, it's a very crude way to avoid parity (mostly because it doesn't really at avoid it at all), this is just how I tried to tackle them without having seperate parity steps.

I'm not sure on what the OLL and PLL parities are, but I'm guessing the OLL parity is when you have the cube solved except one dedge is inversed. If this is the case, there is an extremely easy alg to learn for this (pulled from Chris Hardwick's page on 4x4, and treat all moves using both layers at a time as one turn instead of two separate turns, such as Rr you turn both layers at the same time):

(Rr)2 (Bb)2 (Uu)2 (Ll) U2 (Rr)' U2 (Rr) U2 (Ff)2 (Rr) (Ff)2 (Ll)' (Bb)2 (Rr)2

Granted this alg also messes up the two corners, but if you notice this during your OLL anyway (which is very easy, if you only have one dedge oriented correctly, you know you have OLL parity), but it's much better than the version of the alg that only affects the dedges. And that version is basically take out the outside R's and L's, so you'd only turn the second layer r and l.

If you solve all edges first you will only get parity in the centers where it is undetectable. This is the method in the booklet that came with my Rubik's 4x4. (a very poorly written booklet IMO)

It's basically one piece at a time. Like it was already stated, the method is not suitable for speed cubing. There are about 4 easy algs and the rest is intuitive.

The steps are: solve one side , solve the edges on the opposite side, flip any middle edges that are flipped, solve the middle edges, move the center pieces one at a time until it's solved. It usually takes 4+ min

As far as I know there are two parity cases to learn. Well worth the effort.

I'm not sure on what the OLL and PLL parities are, but I'm guessing the OLL parity is when you have the cube solved except one dedge is inversed. If this is the case, there is an extremely easy alg to learn for this (pulled from Chris Hardwick's page on 4x4, and treat all moves using both layers at a time as one turn instead of two separate turns, such as Rr you turn both layers at the same time):

(Rr)2 (Bb)2 (Uu)2 (Ll) U2 (Rr)' U2 (Rr) U2 (Ff)2 (Rr) (Ff)2 (Ll)' (Bb)2 (Rr)2

Granted this alg also messes up the two corners, but if you notice this during your OLL anyway (which is very easy, if you only have one dedge oriented correctly, you know you have OLL parity), but it's much better than the version of the alg that only affects the dedges. And that version is basically take out the outside R's and L's, so you'd only turn the second layer r and l.

I also only use just this one algorithm to handle edge flip parity (OLL parity). I think some people use a more finger friendly algorithm. The parity is easy to recognize just as you finish F2L. For bigger cubes like 7x7 you sometimes want to do just one or 2 individual slices in place of the wide turns.

It should be noted before you read this post; for reduction, it's much easier to simply execute the parity alg upon discovering it after reduction than to solve the centres then trace the cycles to find out if you will have parity or not to fix it early.

You're thinking "I wonder if anyone has had this idea". The answer is always yes.

If that's all you care about, I'd stop reading now.

It has the cases, but saying you can have two parities on the same solve is incorrect. PLL parity isn't considered parity unless you have reduced to a pseudo 3x3x3 stage. Parity is a different thing when you direct solve, and the effect it has on the solve changes appropriately.

I know you know this, I'm just elaborating for others.

When direct solving with K4 or similar, there is only the edge permutation parity caused by an uneven number of inner slice turns.

Specifically, this parity does not effect the number of algorithms you use in a solve with the K4 method like it does in the reduction method. I imagine people don't know this. The edges of the last layer are solved in three algorithms - the first two are for direct solving two edge pairs to their slots, to leave you with two more (unpaired) edge pairs to solve.

Now, there are a number of senarios that can happen;

1) a 2 cycle to solve (parity)
2) a 3 cycle to solve (no parity)
3) a 4 cycle to solve (parity)
4) a 2x2 cycle to solve (no parity)

Each of senarios can be solved in a single algorithm. There are only 24 cases, and if you can solve them all, parity will no longer cause you to execute extra algorithms since if it actually happens, you can solve the parity and complete the other edges at the same time. So it doesn't really give you more to solve for half the solves you do, it just gives you different cases to solve each time.

I dealt with the orientation parity by using ZZ. by pairing the edges and placing them oriented on the sides (using M freeslice) you could guarentee that those edges were oriented. After solving the EOline there are only 4 edges left to pair, which can be done in 2-3 algs.

Then I had to worry about the "PLL parity". I found that if the blocks were solved ZZ style and the corners done with COLL, the LL edges can be solved with parity, with only 5 more algs (1 being the standard PLL parity alg).

But, because I have left ZZ for Roux, ZZ blockbuilding and COLL won't be used by me again, so I abandoned this idea, very well knowing that it could be extremely fast, faster than K4 even (don't say I didn't warn you Kir).

After you read this post you'll find out that K4 already used similar techniques in a more efficient manner and that it isn't usable in the way you described.

I dealt with the orientation parity by using ZZ. by pairing the edges and placing them oriented on the sides (using M freeslice) you could guarentee that those edges were oriented. After solving the EOline there are only 4 edges left to pair, which can be done in 2-3 algs.

Then I had to worry about the "PLL parity". I found that if the blocks were solved ZZ style and the corners done with COLL, the LL edges can be solved with parity, with only 5 more algs (1 being the standard PLL parity alg).

That makes sense. It's a good idea and part of the reason K4 can be so fast.

The reason I chose ZZ was that it made it easy to pair edges while still determining how many edges were unoriented (0), and could also be done mostly intuitively, which is great for me. Not the fastest, but good for me.

But, because I have left ZZ for Roux, ZZ blockbuilding and COLL won't be used by me again, so I abandoned this idea, very well knowing that it could be extremely fast, faster than K4 even (don't say I didn't warn you Kir).

After you read this post you'll find out that K4 already used similar techniques in a more efficient manner and that it isn't usable in the way you described.

After you read this post you'll find out that K4 already used similar techniques in a more efficient manner and that it isn't usable in the way you described.

Ok. I paired the remaining 2 dedges in such a manner that both are correctly oriented (in terms of 3x3 edge orientation). This guarentees no "OLL parity" because we know that the remaining dedges are oriented as well.

After you read this post you'll find out that K4 already used similar techniques in a more efficient manner and that it isn't usable in the way you described.

Ok. I paired the remaining 2 dedges in such a manner that both are correctly oriented (in terms of 3x3 edge orientation). This guarentees no "OLL parity" because we know that the remaining dedges are oriented as well.