• 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.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Avoiding parity errors in 4x4x4?

Karma Cat

Member
Joined
Nov 24, 2009
Messages
40
Location
Sweden
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 =)
 

joey

Member
Joined
Apr 8, 2007
Messages
4,413
WCA
2007GOUL01
YouTube
Visit Channel
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
Joined
Feb 27, 2009
Messages
3,049
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

Premium Member
Joined
May 13, 2007
Messages
3,923
Location
Denver, CO
WCA
2007COHE01
YouTube
Visit Channel
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
Joined
Feb 27, 2009
Messages
3,049
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
Joined
Nov 28, 2009
Messages
1,796
WCA
2010LACH01
YouTube
Visit Channel
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
Joined
Jun 17, 2009
Messages
82
Location
Belgium WVl
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
 

radmin

Member
Joined
Feb 25, 2010
Messages
401
Location
Columbus, Ohio
WCA
2010HARD02
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:
Joined
Apr 17, 2008
Messages
735
Location
Massachusetts, USA
WCA
2009JOHN07
YouTube
Visit Channel
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
Joined
Mar 26, 2006
Messages
6,121
WCA
2006BARL01
YouTube
Visit Channel
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.

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
Joined
Feb 27, 2009
Messages
3,049
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:

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
WCA
2006BARL01
YouTube
Visit Channel
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
Joined
Feb 27, 2009
Messages
3,049
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
Joined
Mar 26, 2006
Messages
6,121
WCA
2006BARL01
YouTube
Visit Channel
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.
 
Top