# Avoiding parity errors in 4x4x4?

#### Karma Cat

##### Member
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 =)

#### Muesli

Nope and tough, learn them.

They aren't really hard and you get into a rhythm.

#### crazymanjimbo46

##### Member
Unless you want to cheat then there is no way to avoid them, that's way they don't allow more than one logo on any cube in the WCA.

#### Karma Cat

##### Member
Ah, I see, I see. Guess I'll just have to keep practicin' then. Cheers =)

#### joey

##### Member
Unless you want to cheat then there is no way to avoid them, that's way they don't allow more than one logo on any cube in the WCA.
There IS a way to avoid it, but it's too hard/lengthy for speedcubing.

And parities aren't that long, you could have learnt them in the time it took you to make this thread.

#### miniGOINGS

##### Member
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 =)

Not for Kirjava.
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).

#### masterofthebass

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 =)

Not for Kirjava.
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.

#### miniGOINGS

##### Member
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.

#### FatBoyXPC

##### Member
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.

Last edited:

#### Am1n-

##### Member
Just do cage, only one parity case in the u slice, which can be solved with: one u turn (= 4-cycle) + one 3-cycle of edges.

mvg

##### Member
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.

Last edited:

#### rjohnson_8ball

##### Member
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.

#### Kirjava

##### Colourful
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.

Learn K4 method
still has OLL and PLL parity.

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.

This makes no sense.

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 is getting to the right territory, it's kinda like what I do in K4, solving parity while solving other things.

You can do this specific thing in redux, it's not a ZZ only thing - see Dan's notes on why it isn't feasable for your methods.

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.

#### miniGOINGS

##### Member
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.

This makes no sense.
Do you mean you don't get what I'm saying, or that it is logically incorrect?

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 is getting to the right territory, it's kinda like what I do in K4, solving parity while solving other things.

You can do this specific thing in redux, it's not a ZZ only thing - see Dan's notes on why it isn't feasable for your methods.
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.
Could you explain a bit? I think you're talking about solving parity while pairing up another dedge, but I'm not completely sure.

Last edited:

#### negative_earth

##### Member
i'm just a newbie in speedcubing, so i just sucks it up and memorize them all hahahaha

#### Kirjava

##### Colourful
Do you mean you don't get what I'm saying, or that it is logically incorrect?

I don't understand how what you decribed "deals with" OLL parity.

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.
Could you explain a bit? I think you're talking about solving parity while pairing up another dedge, but I'm not completely sure.

I did already explain in my previous post, read it again. You don't pair in K4.

#### miniGOINGS

##### Member
Do you mean you don't get what I'm saying, or that it is logically incorrect?

I don't understand how what you decribed "deals with" OLL parity.
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.
Could you explain a bit? I think you're talking about solving parity while pairing up another dedge, but I'm not completely sure.

I did already explain in my previous post, read it again. You don't pair in K4.
Ahhh, Ok. I think I understand now, I was thinking incorrectly.

#### Kirjava

##### Colourful
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.

Can you tell me how you managed to do this? It's impossible to flip an edge by unpairing and pairing, so I see delusion.

you can do it with some K4 algs, actually - but we both know you arn't doing that.