Avoiding parity errors in 4x4x4?

[miniGOINGS]

Ok. Let me ask you a question. Your current strategy is to pair up 8 dedges in L and R so that the remaining 4 (maybe less) are in M only.

From there you paired up two more dedges.

Is this correct?

No. I solved the L&R centers. From here I use the M slice to pair and orient 6 edges and place them at LB LD LF RB RD RF. I usually do the L side first, and then R, making sure that I leave out the 2 dedge pieces for the next step. I then solve the remaining centers and the DF DB dedges, similarly to KBCM, but being able to do D2 F2 and B2 without undoing those moves (because it just switches dedges. Then in 2 or 3 algs I paired up the remaining 4 dedges making sure they're oriented correctly. From here its ZZ blockbuilding, COLL, and EPLL with 50% chance of parity.

 

[miniGOINGS]

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.

Actually, I am using K4/KBCM algs for this. I found all of the cases for the last 2 dedges (on your site), and then cut the number of cases in half (because we don't carry about the permutation of the dedges in perspective to each other). Another way I thought up of (only if it's lucky) is to "orient" the 8 edges on top, and then cycle them. If I finished the cases for this, I would only use it for cases with 0, 2, or 4 "unoriented" edges.

 

[ZamHalen]

(An idea i'm working on i just don't have 4x4x4)I've been trying to see if there is a way with a petrus style solve to avoid OLL (and maybe PLL but PLL parity is easy) parity.The idea is that you get your centers then pair up enough edges to make a 3x3x4 block.Then you pair the rest of the edges towards the U face correctly oriented.I'm not sure if this would work as I have no 4x4x4 and hate using computer 4x4x4's.Has anyone else thought of this?

 

[Kirjava]

Actually, I am using K4/KBCM algs for this. I found all of the cases for the last 2 dedges, and then cut the number of cases in half (because we don't carry about the permutation of the dedges in perspective to each other).

So you're using a permutation parity algorithm instead of doing OLL parity after redux. To be honest, it's probably about the same as ignoring it and just doing OLL parity later on. Pairing is essentially negligible and the algorithms you're using are likely wasteful since they're 'pure' versions. This needs further development before it's actually useful imo.

Good ideas, but they don't seem to work out that well in practise.

 

[ZamHalen]

(An idea i'm working on i just don't have 4x4x4)I've been trying to see if there is a way with a petrus style solve to avoid OLL (and maybe PLL) parity.The idea is that you get your centers then pair up enough edges to make a 3x3x4 block.Then you pair the rest of the edges towards the U face correctly oriented.I'm not sure if this would work as I have no 4x4x4 and hate using computer 4x4x4's.Has anyone else thought of this?

As soon as you said, "The idea is that you get your centers then..." I already knew the answer to your question.

The answer is NO, this will not prevent OLL parity (well it will if you don't have it in a given solve to begin with ).

Once you solve the centers without first counting cycles of the wing edges, then there is definitely no chance you can prevent OLL parity.

As I said I've never tried it and to tell you the truth i didn't actually think it would work anyway.(It was more of a passing thought thing.)

 

[miniGOINGS]

So you're using a permutation parity algorithm instead of doing OLL parity after redux. To be honest, it's probably about the same as ignoring it and just doing OLL parity later on.

I'm not sure I get what you're saying there.

Pairing is essentially negligible and the algorithms you're using are likely wasteful since they're 'pure' versions. This needs further development before it's actually useful imo.

Good ideas, but they don't seem to work out that well in practise.

I completely agree with you. If I hadn't switched back from ZZ, I definitely would have continued to develope this, and probably seek assistance from knoledgable people like you. I think that once refined, this could be good, but as of yet, it is very crude.



EDIT: One thing I have learned from this "conversation" that I never thought about before, is that parity is essentially determind once centers are finished. I know it makes sense, but I never thought about this before.

 

[Kirjava]

So you're using a permutation parity algorithm instead of doing OLL parity after redux. To be honest, it's probably about the same as ignoring it and just doing OLL parity later on.

I'm not sure I get what you're saying there.

Permutation parity is different from PLL parity. It's the one caused by an odd number of inner slice turns.

I completely agree with you. If I hadn't switched back from ZZ, I definitely would have continued to develope this, and probably seek assistance from knoledgable people like you. I think that once refined, this could be good, but as of yet, it is very crude.

ZZ is def. useful when using this technique, I just can't think of a way to apply this concept in any way that makes it worth it to use right now.

 

[miniGOINGS]

So you're using a permutation parity algorithm instead of doing OLL parity after redux. To be honest, it's probably about the same as ignoring it and just doing OLL parity later on.

I'm not sure I get what you're saying there.

Permutation parity is different from PLL parity. It's the one caused by an odd number of inner slice turns.

I understand, I just don't get where I'm doing this.

ZZ is def. useful when using this technique, I just can't think of a way to apply this concept in any way that makes it worth it to use right now.

Good point. I've also toyed with the idea of solving the D and B centers, pairing up the DB dedge (really easy) and inserting it. Then somehow pairing the remaining edges in multiple steps (while solving DF and making sure the dedges are oriented). From here the last 2 centers can be solved in one, short, quick, alg.

Spoiler

r U l' U' r' U l
r U' l' U r' U' l
l' U r U' l U r'
l' U' r U l U' r'
l' U' r U l U2 l' U r' U' l
l' U' r U l U2 l' U r' U2 r U l U' r'
...

Just to let you know, I have thought about this a lot, I just don't know what's practical or not because I don't have 4x4 experience (redux or direct solving).

 

[DavidWoner]

it's a very crude way to avoid parity (mostly because it doesn't really at avoid it at all)

Pretty much this.

 

[calekewbs]

just learn cage. it's not difficult at all and there is no parity.

 

[richardzhang]

You could use cage method

 

[joey]

just learn cage. it's not difficult at all and there is no parity.

No, No. This is wrong.

 

[calekewbs]

just learn cage. it's not difficult at all and there is no parity.

No, No. This is wrong.

How is this wrong? The person that taught me most of everything I know taught me cage method first simply because of those reasons. It really isn't dificult either. It is really just a bunch of intuitive stuff and then commutators.

 

[joey]

There IS parity.

 

[Kirjava]

So you're using a permutation parity algorithm instead of doing OLL parity after redux. To be honest, it's probably about the same as ignoring it and just doing OLL parity later on.

I'm not sure I get what you're saying there.

Permutation parity is different from PLL parity. It's the one caused by an odd number of inner slice turns.

I understand, I just don't get where I'm doing this.

If you understood, you'd get where you were doing it (if you are even doing it at all). You can't fix OLL parity without doing it.

 

[calekewbs]

and that parity would be?

EDIT: I should probbably explain to you the way I do cage.

1: get two opposite centers
2: pair up 4 edges of one of the colors you solved.
3: make the cross with those edges.
4: Insert corners to make a layer
5: fix opposite layer corners
6: input opposite layer edges as many as possible at a time
7a (only on odd cubes): fix middle layer edges
7b: use an algorithm that switches a wing edge from the d layer to the u layer. Do this until you have all the edges in one lf the inner layers solved.
8: use a 3-cycle at most twice to solve the remaining edge pieces.
9: solve the remaining 4 centers with a simple commutator

There is no parity in there.

 

[joey]

Can you show me 7b?

 

[Kirjava]

There is a parity, probably in step 8, you have to perform at least a single inner slice move for specific cases to fix the edge permutation parity.

Just because it's easy doesn't mean it doesn't exist.

UBr and UFr are swapped in this image. You cannot solve it with 3-cycles alone.

Show me how you'd solve it; remember that an odd number of inner slice turns means that you will be fixing the edge permutation parity.

 

[miniGOINGS]

Ok. So final verdict is:

There is no speedsolvable way to completely avoid parity on the 4x4.

Correct?

 

[miniGOINGS]

Yes, that is correct unless you can count the cycles of the wing edges during inspection time.

I'm guessing that would take more than 15 seconds?